Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Resolving the great undo-redo quandary

github.com

Post reply on HN
Print view View original

41–50 of 247 posts

Re: Resolving the great undo-redo quandary

#41

Post by rcthompson »

Chris2048 wrote: post #39
rcthompson wrote: post #4

This is exactly how undo works in Emacs out of the box. Personally, I prefer to install the undo-tree package and manually browse through the tree of undo paths. I'm not sure why this author finds a tree unacceptable for this purpose.

Sounds like this solution would best be implemented with an undo-tree, but also a linear history mapping with pointers to that tree - the linear history would just log movement within the tree over time e.g. undo-redo would just be a backwards-forwards movement.

That's exactly what you get with undo-tree. The regular undo/redo commands continue working as normal, but you can also manually browse the tree if things get too nonlinear for you.

Re: Resolving the great undo-redo quandary

#42

Post by Chris2048 »

323 wrote: post #15

Many times I want to undo to a previous state, but then apply again a few of the changes I just reverted, basically cherry-picking from the future (from the redo stack). It would be interesting to be able to see all edits as individual patches/diffs that you can commit/discard individually. Like a mini automatic git inside the editor, automatic in the sense that every "edit" creates a commit, undo/redo move HEAD. Thi…

If the changes "conflict" it might be best to use a "smart" editor that can somewhat figure out changes on a higher level.

Re: Resolving the great undo-redo quandary

#43

Post by tmtvl »

gpvos wrote: post #26
rcthompson wrote: post #4

This is exactly how undo works in Emacs out of the box. Personally, I prefer to install the undo-tree package and manually browse through the tree of undo paths. I'm not sure why this author finds a tree unacceptable for this purpose.

And it is exactly why I find Emacs undo so hard to work with. But maybe I will get it now I've read this article.

You can, if you like, install the 'vundo' package, which gives you a tree-based overview of your undo history, making it easy to switch between branches and go backward and forward. It's basically like the undo-tree view for the default undo mechanism.

Re: Resolving the great undo-redo quandary

#44

Post by headPoet »

quartz wrote: post #36

Semi-related: What I really wish all my editors and IDEs would have is some kind of "delete history" view into my deleted text (especially blocks of text). I'll often delete something, then work for a while, then realize I need that thing back again so I have to VERY carefully undo everything after the delete until I get to a point in history before it, copy the deleted text, then re-do everything back to my original…

A lot of IDEs (I know Eclipse and VSCode both do this) will create a copy of the file you're working on each time you hit save. You can then navigate back through the local history of the file.

I'm conditioned to hit Ctrl+S with almost every change, so this gives me a very detailed history of my revisions.

Re: Resolving the great undo-redo quandary

#45

Post by nerdponx »

ctrlmeta wrote: post #21

> No, there is no undo "tree", nor any complicated graphical user interface to go with. ... You've got your undos, your redos, and that's it. The underlying data structure is strictly linear, but all edit states are preserved and reachable ... This is exactly how Emacs works! Emacs has worked like this since its beginning in 1980s. It was even documented in the first manual (1981): This might seem to pile one disaste…

Vim also has an undo tree, although you need a plugin to work with it easily (called "Undotree").

Re: Resolving the great undo-redo quandary

#46

Post by 323 »

alisonatwork wrote: post #31
323 wrote: post #23

Earlier quoted context omitted.

VS Code has that feature too, but only for individual files.

I wish VS Code would expand on that feature, coming from IntelliJ. It's really annoying that you need to type the name of the file you want to see the local history of, even when it's the currently active file in the editor. There should be a sidebar widget for it that's active for whatever the current file is. The cool thing with IntelliJ is if you accidentally deleted a file you can just touch a blank version of th…

There is a sidebar widget. But it starts merged in the File Explorer view, and you need to drag it over from there to the sidebar to make it independent - https://stackoverflow.com/a/71522634

The widget is called "Timeline".

> The cool thing with IntelliJ is if you accidentally deleted a file you can just touch a blank version of the file and the history comes back. Not sure if VS Code does that yet.

VS Code does keep the history after file deletion, but I'm not sure how to access it from inside.

I had to manually rummage through the storage directory to find a file I accidentally deleted, but it was an file which was never saved (think Untitled), so it didn't had a path that I could try creating a blank file at.

Re: Resolving the great undo-redo quandary

#47

Post by lelanthran »

quartz wrote: post #36

Semi-related: What I really wish all my editors and IDEs would have is some kind of "delete history" view into my deleted text (especially blocks of text). I'll often delete something, then work for a while, then realize I need that thing back again so I have to VERY carefully undo everything after the delete until I get to a point in history before it, copy the deleted text, then re-do everything back to my original…

Vim stores all deleted text automatically, up to a max of 10, I think.

Probably very possible to extend that with some advanced vimscripting.

Re: Resolving the great undo-redo quandary

#48

Post by cpcallen »

lelanthran wrote: post #47
quartz wrote: post #36

Semi-related: What I really wish all my editors and IDEs would have is some kind of "delete history" view into my deleted text (especially blocks of text). I'll often delete something, then work for a while, then realize I need that thing back again so I have to VERY carefully undo everything after the delete until I get to a point in history before it, copy the deleted text, then re-do everything back to my original…

Vim stores all deleted text automatically, up to a max of 10, I think. Probably very possible to extend that with some advanced vimscripting.

In this thread: people discussing all the excellent features they wish their text editor had that emacs (and/or vim) has had for literally decades.

Re: Resolving the great undo-redo quandary

#49

Post by vvillena »

quartz wrote: post #36

Semi-related: What I really wish all my editors and IDEs would have is some kind of "delete history" view into my deleted text (especially blocks of text). I'll often delete something, then work for a while, then realize I need that thing back again so I have to VERY carefully undo everything after the delete until I get to a point in history before it, copy the deleted text, then re-do everything back to my original…

Jetbrains IDEs can do this using the local history feature. Browse through time on a separate tab, copy what you need, and paste it back into the present.

Re: Resolving the great undo-redo quandary

#50

Post by xixixao »

quartz wrote: post #36

Semi-related: What I really wish all my editors and IDEs would have is some kind of "delete history" view into my deleted text (especially blocks of text). I'll often delete something, then work for a while, then realize I need that thing back again so I have to VERY carefully undo everything after the delete until I get to a point in history before it, copy the deleted text, then re-do everything back to my original…

You can use “cut” instead of “delete” and clipboard with history tracking, for example Alfred on macOS.

Then you cut, do some changes, and later on realize you wanted something from the cut code, bring out the clipboard history and fish out what you need.

Post reply on HN