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

81–90 of 247 posts

Re: Resolving the great undo-redo quandary

#81

Post by ctrlmeta »

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.

> If so it seems unclear where to draw the line. If not it sounds nonfunctional.

There is no line. It is just one long linear list. An undo operation is an edit to the text after all. So the edit made by the undo operation also goes as a text edit operation in the undo list.

This is the way undo has always been in Emacs. I wouldn't say it is nonfunctional. I use this in Emacs undo, redo (which is undo-of-undo) and it feels okay most of the time. It is good to know that Emacs will never lose any edit even if I have performed a confusing series of undos and redos. But it can get confusing pretty soon if we are undoing and redoing on the same edit too many times.

That is why many people don't like linear undo history and install an undo-tree plugin which makes undos easy to navigate in a tree. Yet another reason to design some computer/software history lessons so that devs can learn from the existing techniques, their adoption, benefits and complaints.

Re: Resolving the great undo-redo quandary

#82

Post by IshKebab »

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.

Yeah for something that is supposedly intuitive this is the worst explanation I have ever read. I think what he's saying is that:

It works exactly like normal undo/redo, but if you make an edit that would normally wipe your "redo stack", then instead that redo stack is moved into the undo stack.

So:

  Type "hello"
  Type "world"
  Type "!"
  Undo
  Undo
  (Editor is "hello", with "world" and "!" on the redo stack)
  Type "dave"
  (This would normally wipe the redo stack but instead it moves it to the undo stack)
  Undo
  (Editor is "hello")
  Undo
  (Editor is "helloworld")
  Undo
  (Editor is "helloworld!")
  Undo
  (Editor is "helloworld")
  Undo
  (Editor is "hello")
I like the idea. It's a little weird that typing changes the undo stack but it already can change the redo stack so I don't think it matters.

It needs an understandable explanation and ideally a web demo to gain traction though.

Re: Resolving the great undo-redo quandary

#83

Post by [deleted] »

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…

[deleted]

Re: Resolving the great undo-redo quandary

#84

Post by Chris2048 »

rcthompson wrote: post #41
Chris2048 wrote: post #39

Earlier quoted context omitted.

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.

The one I saw had you browsing the tree, rather than a linear history representation of a tree.

Re: Resolving the great undo-redo quandary

#85

Post by randomsearch »

Relatedly, have you ever thought about how undo works with text?

Open your mail client, compose a message, type a few words. What do you expect cmd-z to do? How much of the words will it undo? All the line? Try it.

Then after undo, type a bit more. Hit enter and cursor back. Type again.

Undoing typing is no trivial matter.

Re: Resolving the great undo-redo quandary

#86

Post by 323 »

jasonlotito wrote: post #74
spullara wrote: post #16

Earlier quoted context omitted.

Use local history in any JetBrains IDE.

Seriously. This is one of those features I forget other people don't have access to. Anything less is just uninspired.

VS Code has this feature too, it's just not known.

Re: Resolving the great undo-redo quandary

#87

Post by rando14775 »

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.

In Emacs, undo makes an undo pointer go down in the undo stack. Pressing undo again goes back another step. If you do any other regular edit, the pointer starts over at the top of the undo stack. Undo puts its own edits on top of the stack like any other command.

So if you "undo, undo" you undo two things. If you "undo, edit, undo", you're keeping the first undo but reverse the edit. If you "undo, edit, undo, undo", you're back to where you started (except your undo stack has now grown).

Re: Resolving the great undo-redo quandary

#89

Post by unholiness »

jefftk wrote: post #75
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.

The way this approach is implemented in Emacs is that it depends on whether your previous action was an undo. A: A A B: AB A B C: ABC A B C undo: AB A B C undo undo: A A B C undo undo D: AD A B C undo undo D undo: A A B C undo undo D undo undo: AB

Interesting. So basically the last chain of undo doesn't enter the history until you do something else.

I often use undo as a faster delete when making edits, so I think I would still be annoyed by this (why am I seeing this crap I undid reappearing?) Now after a long undo chain I'm afraid to type for a new reason: it will pollute my undo stack. But it might be reasonable if my brain was used to it. Can't knock something I've never tried.

Re: Resolving the great undo-redo quandary

#90

Post by unholiness »

osrec wrote: post #80
dmix wrote: post #69

Earlier quoted context omitted.

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

I feel things work most intuitively if the undo/redo functions simply navigate the history, but do not themselves form part of the history.

That's how every other undo works. The whole GRUQ is caused by undos not themselves forming a part of history...
Post reply on HN