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

61–70 of 247 posts

Re: Resolving the great undo-redo quandary

#61

Post by tartoran »

xixixao wrote: post #50
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.

Yes, but having thousands of snippets in a bucket can be quite confusing too, where do the pieces go back and so on.

For this reason I comment out code then keep it until I’m sure I no longer need it. This works in sessions, and do the final delete, clean up etc at the end of the session before committing the changes to the repo. I see devs keeping commented out code in repos but that adds too much noise, makes the code a real mess..

Re: Resolving the great undo-redo quandary

#62

Post by JackFr »

cpcallen wrote: post #48
lelanthran wrote: post #47

Earlier quoted context omitted.

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.

And/or JetBrains.

Makes me wonder honestly what tool in widespread use doesn’t have this? Notepad?

Re: Resolving the great undo-redo quandary

#63

Post by Larrikin »

vvillena wrote: post #49
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.

Whats even more amazing is that you can right click the package/folder and get local history and see entire files that you previously deleted.

Took me a while to discover this but has saved me almost as many times as local history in a file. Also makes me feel much better when refactoring and deleting tons of old code.

Re: Resolving the great undo-redo quandary

#64

Post by lostcolony »

zwkrt wrote: post #59
nerdponx wrote: post #45

Earlier quoted context omitted.

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.

And that you still want a linear path through your undos and redos...and that's something that Emacs does.

Re: Resolving the great undo-redo quandary

#65

Post by JackFr »

spullara wrote: post #16
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…

Use local history in any JetBrains IDE.

And with the diff panel you can easily cherry pick selected changes to apply.

Re: Resolving the great undo-redo quandary

#66

Post by unholiness »

Feels like I'm missing something...

If I press ctrl-z ctrl-z, I expect the last 2 things typed to be undone. Based on what he's saying, the first ctrl-z undoes one step, and the second ctrl-z undoes the undo i.e. puts me back where I started, with no way to get back further.

Is there a special case for multiple undo's in a row? If so it seems unclear where to draw the line. If not it sounds nonfunctional.

Re: Resolving the great undo-redo quandary

#67

Post by zwkrt »

ec109685 wrote: post #57

In 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?

In the author’s algorithm there is no two branches. The following diagram is an undo tree where we made change B, went back to A, then made C

      C ——— now
     /
 —— A
     \
      B
But time doesn’t branch, so our history shouldn’t /have to/ branch. What if our undo was itself part of the linear history? Then we could build up the history like this:

  A
  A —— B
  A —— B —- undo_B
  A —— B —— undo_B —— C
For complex undo/redo scenarios this could get out of hand.

  A — B — undo_B — C — undo_C — undo_undo_B —undo_B — undo_A…
But the author (I think correctly) states that for the average user this behavior is intuitive and desired.

They also added the optimization that undoing and then redoing a set of changes doesn’t make it into the history, as it’s basically a no-op.

Re: Resolving the great undo-redo quandary

#68

Post by chrisshroba »

xixixao wrote: post #50
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.

Maccy is a great free and open source clipboard history tool with a nice interface (Alfred requires the power pack purchase for this feature)

Re: Resolving the great undo-redo quandary

#69

Post by dmix »

unholiness wrote: post #66

Feels like I'm missing something... If I press ctrl-z ctrl-z, I expect the last 2 things typed to be undone. Based on what he's saying, the first ctrl-z undoes one step, and the second ctrl-z undoes the undo i.e. puts me back where I started, with no way to get back further. Is there a special case for multiple undo's in a row? If so it seems unclear where to draw the line. If not it sounds nonfunctional.

True, at what point do you include the undo itself in the undo history or do you skip it entirely?

Never considered that.

Re: Resolving the great undo-redo quandary

#70

Post by mananaysiempre »

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…

Kakoune, like the more logical Vim it is, has both in a sensible arrangement: an undo tree with a current branch, which you can navigate up and down (u/U), and a linear history of the path you took through that tree, which you can navigate backwards and forwards (/). Unlike a single undo branch, you’re never afraid you’re going to lose your work when you need to go rescue a piece from a previous version; unlike a plain linear history like TFA proposes and Emacs uses, you’re not punished with a quadratic number of undo/redo pairs if you need a point behind several parallel do-overs of the same part. Unfortunately, without any sort of visible representation of all that I frequently find myself getting lost in the whole thing.

(Now that I’m thinking about it, Git’s commit tree and reflog play a similar pair of complementary roles locally.)

Post reply on HN