It's not mentioned in the article but Vim (and NeoVim) keep undo/redo history in a tree rather than a simple linear timeline[1].<p>The practical usage is it's aways possible to get back to a previous state you were in, which is pretty neat.<p>e.g. You can undo 5 changes, try something else and decide that you prefered the text before you started undoing things. In most programs with a linear undo history you've wiped out your previous changes but not in Vim.<p>You can hop about the branches of the undo tree using the g+ and g- commands but it's much easier to add an undo tree visualiser plugin such as the venerable old Gundo[2].<p>1. <a href="https://neovim.io/doc/user/undo.html" rel="nofollow">https://neovim.io/doc/user/undo.html</a><p>2. <a href="https://docs.stevelosh.com/gundo.vim/" rel="nofollow">https://docs.stevelosh.com/gundo.vim/</a>
Emacs has this too, with ‘undo-tree-mode’.<p>(Incidentally, the documentation is wonderful: ‘The only downside to this more advanced yet simpler undo system is that it was inspired by Vim. But, after all, most successful religions steal the best ideas from their competitors!’)
Strange, I love GNU screen, and find the key combinations very easy and intuitive. However, I could never seem to master GNU's Emacs and what I find are very strange default key commands. I love vim for the reason of, what I personally find, very intuitive key combinations.<p>I just downloaded VSCode for the first time recently -- which I was delighted to find has a VIM mode. From what I read VSCode's VIM mode does not respect the undo tree of actual VIM.
A good number of Emacs users work with Vim key bindings. evil-mode is very good. I use Doom Emacs, which uses evil-mode by default.
fun fact: sublime text also has a vim mode (called "Vintage mode" which is just hilarious) that is built-in but disabled by default, rather than an extension like in vscode. vim keybinds are just the best.
I haven’t been using Emacs for a long time now, but isn’t the Emacs way better? With undo tree you don’t lose any history, but the same is true for what Emacs does by default and it is much easier to navigate the history, since every change is part of a linear history and undos and redos also get added to it.
I had occasional problems with undo-tree (the tree broke occasionally), I've been using vundo for a while now and I'm a lot more happy with that.
The mark and diff functionality is great too.
Another day, another great Emacs package I’ve just learned about. This one’s going in the init.el for sure!
undo-tree-visualize is easily one of the biggest wow factors for unfamiliar users. Cannot unsee, cannot go back.
I use undo-tree plugin to use this in a nicer way. It's such a gem!
I figured that this was what this article was going to be about.
I thought so too, it's a part I've always struggled with effectively using, cause I get lost so quickly so was happy for a moment. But then reading the comments first, I got disappointed before I even had a chance to open the article.
If you are going to need this, then you should use git instead of relying on the editor's undo tree.
You could if you remembered to make commits between every small, low value text edit. :P<p>Meanwhile the undo/redo tree is always there, ready to use and has no overhead. You can ignore it completely until you need it to save your arse.
They are both useful. I'm a frequent committer but find myself using this, I wanna say, 0 - 3 times per month. It's one of those things that when you want it, you're really glad it exists.
Consider this capability being used over the span of seconds as just another text editing tool. It would be like saying we don’t need undo/redo at all, just use git.
Don't forget time-travel undo. If you get into a weird state with the undo tree, and g+/g- aren't helping, you can do ":earlier 5m" to go back to where you were 5 minutes ago, and ":later 30s" to step forward.<p>Unfortunately, when you're at "now" you can't do ":later 30m" to see the future.
> you can do ":earlier 5m" to go back to where you were 5 minutes ago<p>That's crazy! I've used vi/vim/neovim for so long, probably two decades, and I've never heard anything about this feature, yet so many cases this would have been helpful.<p>Must be hundreds of these features I still don't know about. What's the wildest less-known vim features people sit on and haven't shared with the rest of us yet? :)
I was gonna make a quip that someone should really get on the ":later" feature, but then I realized that the modern LLM craze more or less is that feature.
I've always remapped ctrl+r to U as u (undo) and U (redo) feel more consistent with other shortcuts. I suspect this already is very common.
I had almost forgotten that single-level undo was ever a thing. I'm sure there are some applications still in production use that don't support multi-level undo/redo though.
Such as the base OpenBSD vi, which only supports a single-level undo, which I am using at this moment (and still learning how to use, after a few decades). vim got curb-canned a while ago due to various "that's nice, but how do I turn it off?" additions, in addition to having more code in header files than vi has in total. vi meanwhile is pretty bloated though has ex filters which are a huge step up from the standard editor. Multi-level undo? Don't really need it.
Its inscrutable undo and redo behaviour is probably the main reason why I never really tried to get further into Emacs. And that's when I had just access to original vi, not vim.
I can not imagine coding without multi-level undo.
[dead]
:q!
!!
;-)
Do you mean<p><pre><code> :e!
</code></pre>
by any chance?
Ah, I see you’re a man of culture as well.
All I need is a classic bad VI. Only thing lacking is syntax colours and multiple undo.
I hate when people using ViM claim that they are vi users or experts...<p>I miss elVis also. ViM should be banned from all distros because it is literally nag-ware and charity ware (Uganda 's children thing). 30 years later we still can't edit files bigger than RAM size unless you want to use swap file ...<p>Even commodore 64 had editors which could edit files bigger than RAM and WITHOUT ANY kind of swapping to the disk.<p>/rant
> ViM should be banned from all distros because it is literally nag-ware and charity ware<p>It's a two-line message on the startup screen. How does that bother you so much?
> I hate when people using ViM claim that they are vi users or experts<p>I'd go a step further and say because I know and use neovim, I'm also a vi user. Sue me :)
> WITHOUT ANY kind of swapping to the disk<p>how?