Live data from Hacker News

Resolving the great undo-redo quandary

github.com

131–140 of 247 posts

Re: Resolving the great undo-redo quandary

#131
post #102

Vim has this, it's :earlier and :later https://vimtricks.com/p/vimtrick-time-travel-in-vim/ :earlier 3 – Undo the last 3 changes :earlier 5m – Go back to the state of the file 5 minutes ago :later 2 – After undoing something, redo the next 2 changes :later 1h – Travel forward through the change history 1 hour Vim also stores the tree of changes, but it's a pain to access without plugins.

I have started to learn Vim about a year ago and still learning new tricks each day

Wait until you say this after 10 years.

Re: Resolving the great undo-redo quandary

#132
post #102

Vim has this, it's :earlier and :later https://vimtricks.com/p/vimtrick-time-travel-in-vim/ :earlier 3 – Undo the last 3 changes :earlier 5m – Go back to the state of the file 5 minutes ago :later 2 – After undoing something, redo the next 2 changes :later 1h – Travel forward through the change history 1 hour Vim also stores the tree of changes, but it's a pain to access without plugins.

What a great feature!

Is the author of that feature here?

If so, I want to know how they could develop such a feature and be so quiet about it.

It's like someone baking a birthday cake and then dropping it down an abandoned well.

Just imagine how much more productive we'd all be if Vim bros were as loud as the crypto bros over the past decade!

Re: Resolving the great undo-redo quandary

#133

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 article says:

The act of undoing need only become part of our linear history if we squash the proverbial butterfly and thus alter "the past"; in that case the act of undoing itself is instantly recorded as a series of changes, by replaying the redo stack onto the undo stack twice: 1) Forwards, for the original changes 2) and then backwards, to record the history of our undoing.

By squash the proverbial butterfly and thus alter "the past" they mean make an edit after undoing.

Re: Resolving the great undo-redo quandary

#134
post #80

Earlier quoted context omitted.

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...

>every other undo

Ahhhhh, some time you should try a little app called Adobe Photoshop.

Re: Resolving the great undo-redo quandary

#136

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" (T…

I think the best strategy to make it intuitive would be to flatten the redo stack as a single command, so that the pile of successive 'undo's gets redone as a single step. In your example:

  Type "hello"
  Type "world"
  Type "!"
  Undo
  Undo
  (Editor is "hello", with "world!" on the redo stack)

  Type "dave"
  (Editor is "hellodave")
  (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 "hello")

Re: Resolving the great undo-redo quandary

#137

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" (T…

[deleted]

Re: Resolving the great undo-redo quandary

#138
post #20

Earlier quoted context omitted.

Agreed. When I write "foobar", delete the last three characters (so that now I have "foo", then I write a "t", I would like to be able to undo the previous deletion (giving me "footbar"), not just adding the last character. Seems to me that would work especially well in editors that have the concept of verbs + objects, like vim's "delete until the end of the line" or "replace current word with...", but maybe it would…

Should it be “footbar”? Or “foobart”? I could see a case being made for either.

Depends on where the cursor is when you press redo, because it was originally inserted at the cursor position.

Re: Resolving the great undo-redo quandary

#139
I absolutely detest emacs' default undo behavior. I find it worse and more confusing than the normal simple stupid algorithm. With undo-tree, it becomes better than normal, but only very marginally so. I use the linear undo and redo it provides every day but only go looking at the tree a few times a year.

Re: Resolving the great undo-redo quandary

#140
This reminds me of the time I nuked all my code by mistake (rm -rf *) and I still had PyCharm open, and I opened their "Code History" tool and un-deleted all my code, immediately proceeded to commit and push whatever state it was in because I was about to freak out.

I think all IDE's should have their own internal copies of code that are housed elsewhere, it has saved me hours of turmoil trying to re-write already solved for code.

Post reply on HN