> There might be plugins that somehow present this info in the interface.
The undotree vim plugin [1] does this, and gives both the file at the time as well as a diff of what changed.
I was going to mention this plugin. I haven't fully mastered quickly jumping around in it, but it's one of those things that when it's useful, it's VERY useful.
nnoremap u g-
nnoremap <C-r> g+
It takes a little bit of getting use to, but it takes care of most instance where I need a previous edit from a minute ago.
Adobe Photoshop is one. Selection changes don't modify the document at all, but they are part of the undo stack. That's because selecting a part of an image isn't as trivial as selecting text.
Sometimes I wish the current selection could be automatically saved in the file too so you could start where you left off if you were halfway through making a complicated selection (I know you can manually save selections, but that's an added step).
I absolutely love this feature. I regularly open a file and undo/redo to figure out where I was editing last.
There is also a command history, and jumplist (movement cursor position history) for things that don't go in the diff tree.
Emacs default undo system is really, really bad. Like worse than the "standard" one. But after installing the emacs undotree it becomes sane.
I wouldn't say that it's worse than the standard, though. Unwieldy as it may be, I like that I can just keep on pressing C-/ and eventually get to the state I want without risk that I may have lost it because I accidentally made a change after a series of undos.
> Emacs documentation recommends using C-f (forward-character) to switch to redo mode, but in my opinion attaching side effect to movement is awful.
I use C-g (keyboard-quit) for that, which is the general let's-not-do-this-anymore keybinding. I think the documentation mentions C-f as an example keybinding that does the needful without much thought on being the "best" keybinding for it.
Are you aware of the `undo-only` (and `undo-redo`) functions? They make it a breeze to navigate even the most complex undo history.
(undo-redo) doesn't seem to be defined in stock Emacs, but undo-tree defines (undo-tree-redo), which does the needful.
My comment was more about lamenting the defaults in comparison with vim's, but it's true that it doesn't take much configuration to make it much better.
I can't imagine it'd be that complicated to add it though, if you really want it. I think it'd just be a matter of hooking to the undo function and maintaining a list of timestamps for each item added to the undo list, then adding a command that lets you specify the number of minutes and figures out the correct undo item it should go back to by using that list of timestamps.
It automatically commits after every change since the IDE was opened, and can easily be diffed and reverted as needed. Reverting saves another entry, so you can revert back to the future as well.
Personally I have found Vim more approachable than IDEs actually. It doesn't throw all those overloaded toolbars at you according to some one-size-fits-all principle. For me it went so far that last year I actually did a Java project in Vim instead of an IDE for the first time, because the latter had grown to be so frustrating to use.
Also, if you go cold turkey, you'll be productive in less than a month, and arrive at a good workflow that fits you in less than six months, flow that you will improve over the years in amazing ways.
Likewise, if you have any recommendations for your preferred workflow I'm sure some will find it useful. Hopefully those who don't use your preferred $EDITOR don't then rush to complain that not everyone uses $EDITOR. ;)
1. Realize I need to check how my new code looked like 5 min back. 2. Copy full file into clipboard, undo by a few steps 3. Do a temp commit on GitHub desktop 4. Paste the new code back and look at the diff on GitHub desktop, and if needed undo the temp commit from above.
Is this more clicks than the vin shortcut? Sure. But I don't have to go learn the internal tree structure representation of my text editor and spend my time in that universe. I have found a way to do what I need to with the tools I have in hand.
This is the same way how the majority of finance runs on excel when they could do better with better programing. In the end whether you get the job done in fields where you're not billed by the second is not dependent on how well you use your tools necessarily.
The other analogy is cars - for most people it's something that gets them places, for others it's a way of life if not at least a more involved proposition.
But if code is your way of life, which it is for many people here, it is beneficial to learn the tools that allow you to do it easier. If someone can see how their code was 5 minutes ago in a few keystrokes, they’re going to take advantage of that significantly more frequently than someone using your cumbersome method.
But for me, every little thing I learn in vim pays off... a thousand times? Macros alone have probably saved me a cumulative few hundred hours. And with every other little thing I learn, compounds with this effect. I write macros much better than I did five years ago, but I still surely have tons of stuff to learn. No IDE will ever compete because vim is just four keystrokes away at any time, no matter where my terminal is.
In vim you can do:
to see the code you had 5 minutes ago.> (1) If you go to a prior state and then make a new change, you can no longer redo and all those changes are lost.
Vim makes a tree, so that doesn't happen with it. When you undo and make a new change, you're just making a new branch. u/Ctrl-r goes from leaf to trunk, but with g-/g+ or :earlier/:later you can walk the whole tree.
Emacs similarly doesn't lose changes in this scenario, but instead of making a tree, it has a ring and undo is an action that can be undone.
> (2) You can not see a side-by-side comparison of the previous version and the latest version.
It's probably not complicated to make a macro or function where you go to a previous version, copy the buffer, paste it in a new one on a new window, return the original buffer to the state you were in, and diff the windows for that side-by-side comparison.
A command like so suffices:
> (3) There is no visual indicator of where you are are in your undo/redo history.Not by default, no. :undolist provides some info, though, and the vimscript undotree() function probably provides all the state of the undotree. There might be plugins that somehow present this info in the interface.
> (5) I have found many actions in code editors that do not get added to the undo stack (e.g., changing a debugger option), which caused me problems in the midst of an annoying bug.
In vim, only stuff that changes the buffer is added to the undo tree. Navigation or changes of the state of the editor (e.g. editor options or vimscript variables) aren't added. Are there really editors where adding actions that aren't changes make sense?
> (6) There is no indication of what steps were "big" or how long ago they happened.
That's also true in vim it seems, at least how "big" they where. Each step does have a timestamp, though.
> (6) It is tedious to backtrack one small step at a time.
You can backtrack by however many steps you want. :earlier also supports specifying by seconds, minutes, hours, days, or file writes.
Most cool of all is that vim can persist the undo history. I don't know how common that is among editors, but in vim you can go to a file you haven't opened in years and undo it all the way to its beginning.