So vi only has one level of undo, which is simply no longer fit for the times we live in now, and also wholly unnecessary given even the least powerful devices that might need to run vi probably have more than enough resources to give at least a few more levels of undo. What I didn’t know, however, is that vi’s limited undo behaviour is actually part of POSIX, and for full compliance, you’re going to need it. As Chris Siebenmann notes, vim and its derivatives ignore this POSIX requirement and implement multiple levels of undo in the obviously correct way.
What about nvi, the default on the BSD variants? I didn’t know this, but it has a convoluted workaround to both maintain POSIX compatibility and offer multiple levels of undo, and it’s definitely something.
Nvi has opted to remain POSIX compliant and operate in the traditional vi way, while still supporting multi-level undo. To get multi-level undo in nvi, you extend the first ‘u’ with ‘.’ commands, so ‘u..’ undoes the most recent three changes. The ‘u’ command can be extended with ‘.’ in either of its modes (undo’ing or redo’ing), so ‘u..u..’ is a no-op. The ‘.’ operation doesn’t appear to take a count in nvi, so there is no way to do multiple undos (or redos) in one action; you have to step through them by hand. I’m not sure how nvi reacts if you want do things like move your cursor position during an undo or redo sequence (my limited testing suggests that it can perturb the sequence, so that ‘.’ now doesn’t continue undoing or redoing the way vim will continue if you use ‘u’ or Ctrl-r again).
↫ Chris Siebenmann
Siebenmann lists a few other implementations and how they work with undo, and it’s interesting to see how all of them try to solve the problem in slightly different ways.
I finally get it. Scrolling on touchpad under macOS doesn’t work for logged-in users. Nice try 🙂
I feel like we really need to reexamine POSIX and unix compliance in general. This isnt a throw the baby out with the bath water, we dont need to get rid of it but like the specifications of these tools needs to updated and tbh the syntactical diffrrences between them could use some work too
I am a hardcore vi user. Any editing I do is in vi, I can do magic with vi.. Even plain vi, actually I mostly use original features of basic vi not vim (besides one described below)
I was trying to switch to vscode for some time but I failed and got back to vi.
And yet… I never missed lack of multilevel undo. Honestly I couldn’t care less, which obviously does not mean that people want it and need it I fully understand it.
What I cannot get is that osnews is devoting a second article to the undo feature 🙂
Actually I think that the more important feature that vim brings as a vi replacement is vimdiff. And for years I though vimdiff is just a stupid visual diff that only allows you to compare the files. What was the major game changer to me is realizing that vimdiff can actually edit both files and manipulate the diffs: it can move the differences from one file to the other. This is brilliant!
After that discovery I literally lost any incentive to learn vscode properly.
I’m convert from Emacs to Vi :). It happened about 20 years ago, when I started using laptops more often, and CTRL-META-ALT combos became too hard on those keyboards for me. Since the beginning I saw vim’s need to “set -nocompatible” setting as strange, and whole effort put by Bram into old vi compatibility as not needed by most users, most likely complicating it’s development too. But I can understand those efforts. Having vi (vim, and later nvim) as my daily driver also helps my servicing work be done much easier, since I have to frequently do something on many different old unix devices. On all those devices you can be sure ‘vi’ is always there and even in default configuration it is very powerful editor.