Bob Beck (OpenBSD) on why vi should stay vi (2006)
21 points by r1w1s1
21 points by r1w1s1
The only real argument here is
I want vi with all it's ususal idiosyncracies so that it's basically the same no matter what system I'm using
but it's not even explained... Vim has the 'compatible' option which (I think?) existed back in 2006, and that is set by default when you launched Vim as vi. What, then, are the idiosyncracies of standard vi that compatible misses? Would one example have been too much?
And to answer my own question, yeah, it would've. This is just a random mailing list email from 2 decades ago rejecting the idea of replacing OpenBSD's vi with Vim - rightfully so, IMO.
Linux distros are collections of software written by other people. When you're looking for a vi to include, Vim is the obvious choice. BSDs are a coherent collection of software maintained by a single group. It makes sense for them to maintain their own vi as part of the base system. Why add a big third-party dependency to your base OS if you might not even need any of the "fancy" features of Vim in the first place.
More broadly, software diversity is good in its own right. I think we would be worse off if all *nixy OSes converged on the same exact set of utilities with the same exact features. Each project should be able to grow in accordance with their goals and priorities. Projects should be able to disagree with each other about the decisions they've made.
And hey, that's why I use Vim instead of Neovim - I like Vim as is, and I don't really like (but respect!) the direction Neovim took. Why wouldn't I use Vim, then?
What, then, are the idiosyncracies of standard vi that compatible misses?
The main one that I trip over is the different ways of doing multilevel undo, where the meanings of u and . flip after the first u
As yet another datapoint: on older versions (using "Original Vi" in vim terminology) I had this setting in my .vimrc:
:map ^L !!dtach -p /tmp/.vi.cmd^Mu^M
to get the equivalent of a poor man's Acme on Linux (It just enables an editor to handle shell history by sending the current line to be run elsewhere). On newer versions this needed to be changed to:
:map <F2> yy:!echo -n '<C-r>"' \| dtach -p /tmp/.vi.cmd<CR>j
Not complaining, just pointing that sometimes you really do wish old things just remained the same and new things with newer bells and whistles were named differently.
Could you explain or give me a pointer about that? Vim fanatic here, really curious about that change
In original vi, there was a single level of undo, and u would flip between the undone and done states – another way of thinking about it is that undo itself was undoable like anything else. Nvi adds multilevel undo with u., u.., u... etc. but crucially still keeps the model of undos being undoable. For example, if we have a file
This is a file
insert "text " before "file"
This is a text file
change " text" to "n example"
This is an example file
and remove " file"
This is an example
We'd have an undo stack like add(" text") → change(" text", "n example") → remove (" file"). If we wanted to go back to This is a text file, we'd do u., after which the undo stack would look like add(" text") → change(" text", "n example") → remove (" file") → undo remove → undo change.
If you were to then use u again, it would undo the most recent undo, and you'd end up at This is an example file. If you are thinking in terms of the more usual undo/redo line you can move forwards or backwards on, it feels like the meaning of u flipped from being undo to being redo.
The nvi man page explains it at least as clearly as I could:
u Undo the last change made to the file. If repeated, the u command alternates between these two states. The . command, when used immediately after u, causes the change log to be rolled forward or backward, depending on the action of the u command.
There’s a longer discussion in the vim help.
Dude gets grumpy because he likes his old toy just fine, but other dude points out why the toy is not that great. First dude yells at kids on his lawn, and because this is the 2000s, calls something "retarded". The world moves on.
I find his tone cathartic. I didn't know I needed this until I read it! So many chuckles too.
On point though, I agree. vi is vi, vim is vim. I, too, use mg these days and have it installed on my linux machines as well.
Mostly filed under "who cares?" but tend to agree, even though I couldn't care less if it's vi or vim. If you're doing more than basic editing you shouldn't be using vi on a remote box in the first place. This debate probably mattered more in the 90s.
If you're doing more than basic editing you shouldn't be using vi on a remote box in the first place.
Why not? I write a lot of software in neovim via SSH.
So install neovim or vim.
FreeBSD also has nvi as vi. It is small and always there. It exists so that you ssh into a minimal install and can edit config files, without adding much to VM / container image sizes. If you are doing a lot of editing, install the editor that you are most comfortable with. There is vi so you can fix any issues that would prevent you from installing packages (network config issues, required proxy settings for package fetch, and so on).
The platform that drives me crazy is Ubuntu, where you get vim if you type vi, but command-not-found if you type vim, unless you install vim, in which case you get a second copy of vim installed for some reason.
I think I was just confused by that assertion coming after not caring about the difference between vi and vim in the comment. If the assertion is that heirloom vi itself is a bit spartan for writing software in 2026 then I tend to agree -- though people are obviously welcome to live their truth!
Heirloom vi is based on Bill Joy’s version from the 1970s. The BSDs come with nvi which is Keith Bostic’s version from 1990ish (based on Margo Seltzer’s Berkeley DB recno access method). My experience of old vi (on old solaris boxes) was that it crashed when I grew my terminal to its usual size, and lacked multilevel undo. nvi is much better than old vi and a lot simpler than vim.
An argument could equally be made for not including vi, but ed, the standard text editor.
Agree. Vi is so bloated. Ed is the only true editor.
When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!
TEXT EDITOR.
Wanna know why OpenBSD has poor performance, no modem FS, etc and at times the survival of the project is at risk?
Well, this behavior is a big part of the problem. Starts from the top and then trickles down to the users.
Vim is the superior alternative and is backwards compatible. There is no reason to use “vi” unless you have very special needs.
Nor there is a reason to use CVS when git exists but… Anyway. Meh. I hope things improve for OpenBSD’s sake because the product itself is a marvel in many respects.
But why would they make the base system depend on Vim? Dependencies have a cost. The base vi gets the job done, and presumably doesn't require much maintenance.
If you want to use Vim, it's a single doas pkg_add vim away.