6 ms·
> Why is it so hard to see code from 5 minutes ago while in the middle of a change? In vim you can do: :earlier 5m to see the code you had 5 minutes ago.
by jolmg 6y ago
> Why is it so hard to see code from 5 minutes ago while in the middle of a change?
In vim you can do:
:earlier 5m
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:
:earlier 5m | %y | later 5m | diffthis | vnew | put | 1d | diffthis
> (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.
- nexthash 6y agoThis is excellent... for Vim users. A lot of developers either are not willing or haven't gotten around to learning the complexities of Vim, and use other IDEs like JetBrains or Eclipse. This workflow won't work for them.
- enobrev 6y agoJetBrains' various apps can do this as well with a feature called "Show Local History". I'm not sure where it is in the menus but you can hit shift twice and type it in. 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.
- Quekid5 6y agoIt's in the context menu for files/classes at least.
- voodootrucker 6y agoThis. I've seen developers _think_ they lost code in Android Studio and spend hours trying to recreate it when it was in local history all along...
- cmehdy 6y agoIIRC you can right-click on the column with line numbers to the left of the main editor and you'll have that option too
- watwut 6y agoEclipse has the same thing.
- ramraj07 6y agoI am one of those "not willing" people. I encounter the same issue discussed here without even thinking about it, and solve it as such: 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.
- justinnhli 6y ago> > (3) There is no visual indicator of where you are are in your undo/redo history. > 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. [1]: https://github.com/mbbill/undotree https://github.com/mbbill/undotree
- dorian-graph 6y ago> undotree 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.
- justinnhli 6y agoDitto. Unless I have to go back a lot of edits, I don't actually use the plugin that often. I've mapped my undo/redo keys to traverse the undo tree instead of the undo stack: 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.
- frosted-flakes 6y ago> Are there really editors where adding actions that aren't changes make sense? 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).
- chrismorgan 6y agoI don’t know about Photoshop, but the selection is part of the document in GIMP.
- iaabtpbtpnn 6y agoWow, I have a lot of vim learning to do. Your pipeline is far beyond my level.
- jolmg 6y ago| in vimscript is like ; in other languages. I'm not sure pipeline is a good name to call it. It's just a list of commands run in sequence.
- im3w1l 6y ago> 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. Emacs default undo system is really, really bad. Like worse than the "standard" one. But after installing the emacs undotree it becomes sane.
- b3n 6y agoWhat is bad about it? It always goes back to the previous state, and if you want to skip previous undo states (so you don't undo an undo) you can use `M-x undo-only`.
- im3w1l 6y agoIt's been over a decade since my bad experience so take my words with a grain of salt. Iirc, the issues I had was that I made a huge history of undos-followed-by-redos-followed by-undos-etc etc and the more I navigated my history the more tangled and out of control it became. I think I also had a problem with often accidentally switching from undo to redo mode. Emacs documentation recommends using C-f (forward-character) to switch to redo mode, but in my opinion attaching side effect to movement is awful.
- jolmg 6y agoI agree. It's cool that it's lossless, but doing a lot of undos and redos makes the history quickly unwieldy to navigate. I much prefer vim's tree implementation. 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.
- 6y ago
- doix 6y ago> 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. I absolutely love this feature. I regularly open a file and undo/redo to figure out where I was editing last.
- Moru 6y agoNetBeans also have this but it's set to 7 days as default. Never looked into this before, just thought it was broken but you can save it for eternity if you want :-)
- john4532452 6y agoThis seems cool. Is there an equivalent feature in emacs ?
- jolmg 6y agoWhat particular feature? :earlier 5m? I'm afraid not. Emacs' C-/ acts like :earlier/:later/g-/g+ in that you can navigate the history across undos, but there's no support for specifying by number of minutes. I don't know if there's a package for it though. Evil-mode (vim emulation in emacs) doesn't seem to have support for that either. 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.
- apocolyps6 6y ago> In vim, only stuff that changes the buffer is added to the undo tree. There is also a command history, and jumplist (movement cursor position history) for things that don't go in the diff tree.