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

121–130 of 247 posts

Re: Resolving the great undo-redo quandary

#121

Post by dahart »

> Second of all, there's no need to include "window shopping" in our recorded history; this is when you undo a ways, take a look around, then skedaddle out of there back to "the present" without changing anything. This is just a matter of moving information back and forth from undo-stack to redo-stack.

Usually the whole reason I might undo for a while is to get back part of something I was working on and merge it into other changes I’ve made since then. I’m curious why the author dismisses this, personally cherry picking old history is my primary workflow with undo. In editors that support the undo history they’re advocating here, like emacs, I’m usually undoing a long way so that I can put something in the clipboard, then redo all the way back and cut-and-paste the previous partial state.

It is nice in emacs that typing after undo doesn’t lose my undone edits, that is handy and is a nice little safety net, but it doesn’t actually solve the problem I normally want to solve.

Re: Resolving the great undo-redo quandary

#122

Post by jasonjmcghee »

indosauros wrote: post #14

FYI if you use Jetbrains/PyCharm, it also provides this (and has saved me many times) Just right click your file and view "Local History"

Yup. And it's full-text searchable, which I've found people generally don't realize. Fantastic feature.

Re: Resolving the great undo-redo quandary

#123

Post by kqr »

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 means silently killing off potentially large amounts of editing history every time you edit after an undo. That's the problem this article is about.

Re: Resolving the great undo-redo quandary

#124

Post by fnfontana »

Izkata wrote: 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

Re: Resolving the great undo-redo quandary

#125

Post by jefftk »

unholiness wrote: post #89
jefftk wrote: post #75

Earlier quoted context omitted.

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 somet…

How is undo a faster delete?

Re: Resolving the great undo-redo quandary

#126

Post by TuringTest »

unholiness wrote: post #89
jefftk wrote: post #75

Earlier quoted context omitted.

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 somet…

Note that if you delete something and press Undo, it restores the content that was there before removing it.

The "branching undo" in the article extends the concept to being able to recover things that were at some point in your "redo" pile, but which in other editors would been have lost when you typed something else while in that state.

As the article explains, the simplest mental model is "rewind in time to the point I was 5 minutes, 10, 15, 20 minutes in the past". If you've been undoing and redoing things, going through that point in the past will retrieve those removals and retrievals.

Re: Resolving the great undo-redo quandary

#127

Post by TuringTest »

jefftk wrote: post #125
unholiness wrote: post #89

Earlier quoted context omitted.

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 somet…

How is undo a faster delete?

If you're only adding content, undo removes the most recent content inserted. But that's a very limited case of everything that undo can achieve.

Re: Resolving the great undo-redo quandary

#128

Post by dullcrisp »

dahart wrote: post #121

> Second of all, there's no need to include "window shopping" in our recorded history; this is when you undo a ways, take a look around, then skedaddle out of there back to "the present" without changing anything. This is just a matter of moving information back and forth from undo-stack to redo-stack. Usually the whole reason I might undo for a while is to get back part of something I was working on and merge it int…

It doesn’t sound like you have a problem though. Just keep doing what you’re doing.

Re: Resolving the great undo-redo quandary

#129

Post by quag »

lelanthran wrote: post #94
nouveaux wrote: post #53

Earlier quoted context omitted.

Vim supports practically unlimited undo with branching history. You can visualize it and hop to any undo with a plugin. https://github.com/simnalamburt/vim-mundo

Yes, but GP wanted something that would just keep all deleted text. Sort of, anytime you delete something, that text gets stored somewhere in case, 2 hours later, you realised you wanted it.

Yes, vim’s “set undofile” will create a persistent undo file that stores all changes to the file indefinitely. You can undo changes made months ago over reboots. If you move the undo file between machines, you can undo on different computers.

Undoing a change from 2 hours ago in the same editing session is the trivial use case for undofile.

Re: Resolving the great undo-redo quandary

#130

Post by TuringTest »

unholiness wrote: post #90
osrec wrote: 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...

That's it. You can think of an undo operation U at time (t) as a new simple command that rolls back the content to a previous version (t-x). If you undo that U operation, it's a new command U' that restores content again to version (t).

The history sequence would then be:

(t) --U-> (t-x) --U'-> (t)

And if you add (A) some new content (c) when in state (t-x), it becomes command , which can itself be undone with commands U'' (to remove A), U''' (to remove U):

(t) --U-> (t-x) --A-> (t+c) --U''--> (t-x) --U'''--> (t)

Post reply on HN