Sounds like the Braid version of undo-redo.
Could you elaborate or provide a link? I haven't heard of the "Braid version of undo-redo" before.
Even if you think you don't like games, Braid was really different
Resolving the great undo-redo quandary
51–60 of 247 posts
Re: Resolving the great undo-redo quandary
#52Semi-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.
Oh cool-- are you saying Alfred will let me override the delete key in the case of highlighted text so it always executes a cut instead?
Re: Resolving the great undo-redo quandary
#53Semi-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.
Vim supports practically unlimited undo with branching history. You can visualize it and hop to any undo with a plugin.
Re: Resolving the great undo-redo quandary
#54> No, there is no undo "tree"[...] This is still a tree, it's just implemented in an array.
The point is that the "tree" is not exposed to the user. I feel the author makes this extremely clear.
Re: Resolving the great undo-redo quandary
#55Earlier quoted context omitted.
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.
Oh cool-- are you saying Alfred will let me override the delete key in the case of highlighted text so it always executes a cut instead?
I think they’re just referring to a clipboard history offered by Alfred, not remapping the delete key
Re: Resolving the great undo-redo quandary
#56Semi-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…
Eclipse has “local history” for each file save operation.
You can even do a graphical diff against each candidate timestamp in a gui wizard
As others have mentioned JetBrains cloned this feature too
Re: Resolving the great undo-redo quandary
#57In this methodology, without exposing the tree, how does the user select between the two branches created after the butterfly is squashed?
It seems like Google Docs does it in an intuitive way where undo / redo works normally, but there’s another time ordered history of the document to select from.
Is this what the author’s approach is advocating?
Re: Resolving the great undo-redo quandary
#58Semi-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…
Just a list of tools that have this, in case you use any of them and didn’t know: Vim - has this with undo tree Emacs - has this as well Jetbrains - IDE’s have this with local history they show changes made. VScode has this I’m pretty sure by default otherwise there’s a plug-in for it since I remember doing it.
Also just want to add something really cool about vim and undo/redos that relates to this post. With vim your able to “block” or “bunch” your changes which allows you to control what an undo will do. For example, going into insert mode and typing a sentence than exiting insert mode would be one “bunch” and undo would undo that entire sentence. If you wanted to you can control it by leaving insert mode after a adding a single word or making a single edit and that will be what the undo will revert. Probably rambling a bit here, but the concept of controlling what will be undone/redone is a really neat feature of vim.
Re: Resolving the great undo-redo quandary
#59> 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").
Yes but the article is specially calling out that using an undo tree is something no one wants.
Re: Resolving the great undo-redo quandary
#60Would be useful if this had a comparison with Emacs, which also resolves the GURQ.
Emacs already implements exactly what they are proposing: an undo operation is just another action added to the chain of states, which can itself be undone.