On Jul 18, 2025, at 12:43 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Modern tools are more
complicated because they do more stuff. Taking your position to the extreme
would have you using a pipeline piped to ed, would it not?
preface: none of this is to contradict your position. I was a little confused about the
implications of your apparently contradictory statements, that if someone worked for you
you’d force them to use vim, but also that people should be free to use what they like,
but I don’t feel like I’m owed an explanation for it, so that isn’t why I’m replying.
I never bothered to develop a complicated .exrc and I don’t do much of my programming in
vi-like editors, so for the most part I’m not super invested in the feature differences
between vi, nvi, vim, etc. I do prefer vi-alikes to other unix editors, but I can cope
with ed when I need to. I probably wouldn’t choose to use Emacs unless I had no other
choice, but I easily understand why some people do. The vast majority of my editor use is
for systems-type tasks, so I don’t imagine it’s difficult to understand why I got here.
When I do use vi for programming, it’s primarily to update existing code, but I could
reasonably live with vi alone, if that was all I had.
I am often surprised at my professional colleagues who insist they need vim in particular,
and complain loudly when a vi-like editor that isn’t vim is all that is available. Almost
without fail, these are the same guys I see get thrown when their terminal emulator isn’t
letting them use the arrow keys to position the cursor, who only ever move the cursor
around one row or column at a time, who only ever i or o, never I or O or A or c or C or $
or 10G or u or w or y or anything, who don’t know how to use any of the ex commands, read
text in from files or commands, or use any number of other features more advanced than
what you got in Windows notepad, and who insist, for some reason, that they need vim to
“copy and paste”. Their incuriousness really serves to give me a reflexive (and as this
thread reveals, admittedly sometimes also unfair) disdain toward someone who claims to
“need” vim.
That’s just an opinon, though, and as such, it’s worth a half pitcher of spit. I try not
to get too hung up about it. Everybody needs a hobby. If it’s pounding ‘k’ and ‘l’ a
hundred and seventy times in a row, then… boogie on down.
Anyway. So it also turns out there are other reasons to prefer classic vi. One of the
larger software projects I maintain (mostly using bbedit) is a network booted embedded
linux system which hosts a ruby-based configuration management system, for doing
standalone policy based configuration control of datacenter hardware resources (e.g. RAID
configuration, firmware versions, BIOS settings, defect detection and reporting, etc.)
It’s a relatively complex system solving a relatively complex problem, and the complex
problem is what I want to stay focused on. So that makes limiting the number of external
dependencies an important consideration for the project. Every external dependency becomes
something that has to be downloaded at runtime, something that takes space in the ramdisk,
and a set of binary artifacts that have to be tracked, integrated, and their lifecycle
managed.
It’s also important to be able to use the embedded linux system to investigate defects in
the configuration management system, when they crop up, and although we get nano “for
free” as a byproduct of having based the nucleus of the system around the Debian
installer, there are a long list of reasons why nano is too obnoxious to live with. It was
worth adding a vi-based editor to the system for such occasions. But the standard ‘vim’
has a relatively long list of external dependencies that we would be forced to carry along
with it, and subsequently, to maintain in perpetuity. Even ‘vim-tiny’ and ‘nvi’ had longer
lists of dependencies than I was happy with. I ended up adding ‘elvis-tiny’ to it, which
is pretty much entirely self-contained. Entirely adequate for purpose, perfect on
maintainability requirements.
This is part of the calculus when folks say they find the feature bloat distasteful. It
isn’t always about end-user experience (though sometimes… what the heck is going on with
Jira these days?!? don’t answer that.)
Which reminds me, tangentially: I often get tripped up by “helpful” vim features (I can’t
tell you how many times I have accidentally opened an unwanted Help panel), but I
categorize those as minor annoyances that I try not to get too hung up on. This time,
though, I was using 'vim' on a remote system in an xterm, and wanted to copy and
paste something into a different window. ‘vim’ took all the mouse events for itself and it
wasn’t obvious (in the moment) how to make it stop. I can’t think of a time I ever wanted
to use a mouse to directly control a vi session. That one made me rage a bit, although it
was simple enough to fix (TERM=vt220, try again). I got over it.
Obviously there is an entirely different set of tradeoffs if you’re installing an editor
on a programmer’s workstation. But I wanted to be very concrete about why I don’t favor
the idea that “vim is a 100% replacement for vi in every possible circumstance”. At least
by the Debian maintainer standards, nvi depends on Berkeley DB. vim depends on SELinux,
libacl, libsodium, gpm, and others. Why? (…he asked, rhetorically)
ok
bear.