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

151–160 of 247 posts

Re: Resolving the great undo-redo quandary

#151

Post by dmix »

kqr wrote: post #123
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 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.

I was thinking maybe you ignore it for the first 10 seconds or even better until the cursor changes to a new position, thqt way quick rewinds work in the moment. But later on you can restore the state with undos factored in.

Re: Resolving the great undo-redo quandary

#152

Post by nwatson »

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…

In Atlassian Sourcetree you can stage the full current file, undo live changes in your editor, make different changes to your live document, and then reapply chunks of your prior changes from staging to live document (actually looks like undoing unstaged chunks).

Re: Resolving the great undo-redo quandary

#153

Post by TylerE »

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.

Wait until you see what intellij can do. It can do that, while also layering it in a logical, graphical diff viewer

Re: Resolving the great undo-redo quandary

#154

Post by feintruled »

TuringTest wrote: post #136
IshKebab wrote: post #82

Earlier quoted context omitted.

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…

I get what you are saying, but I think it is confusing to refer to a 'redo' stack at all. There is only ever one stack, and you are always at the end of it. To go back through time you copy the states onto the stack (stack isn't even the right word, I guess but I'll stick with it)

Consider typing the alphabet

Stack:

  1.a
  2.ab
  3.abc
  4.abcd
Now you 'undo' back to place 2 and type 'x'. But while you are conceptually travelling back in time, what the stack really looks like now is:

  1.a
  2.ab
  3.abc
  4.abcd
  5.abc
  6.ab
  7.abx
A conventional undo stack would leave you stuck at a new place 3: abx, all redos gone. Undos from that point can only take you back to place 1 or 0. (Just tested this out on OS X TextEdit, it does this). With the linear stack, there is no redo, only undo.

I think that is what the article means at least...

Re: Resolving the great undo-redo quandary

#155

Post by jsmith45 »

bo1024 wrote: post #146

Cool! What about a model based completely on the "history" as a list of states of the document over time? There is no "undo" or "redo" operation, we only have "browse backward/forward in time". If you are browsing at a point in the past history, you can just start editing. Then the document state is copied to the end of the history (i.e. the current point in time), followed by your edits, etc. This removes the 2^n pr…

That is basically the same as the proposed skipping of B in navigation. It does however require the ability to put "make document look like X" (where X is the old state) as a single undo stack entry. If your app design allows that, great, squashing all of B into a single entry would work fine.

Such an implementation would be: if you go back and try to make a change, it moves everything from the redo stack to the undo stack (to return the the "present"), adds one entry in that represents atomically changing the document to match the old state you were looking at, and then finally adds the change you attempted to make as a new entry in the undo stack.

Re: Resolving the great undo-redo quandary

#157

Post by TheRealPomax »

jancsika wrote: post #132
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.

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!

You just need to get vim bros going. Just go "omg I hate vi so much" at a tech meetup and sit back for the fire hose of vim features to start.

Re: Resolving the great undo-redo quandary

#158

Post by 0xCMP »

sulam wrote: post #32
rcthompson wrote: post #4

This is exactly how undo works in Emacs out of the box. Personally, I prefer to install the undo-tree package and manually browse through the tree of undo paths. I'm not sure why this author finds a tree unacceptable for this purpose.

He literally says why at the top of the post. People find it too complicated.

No, he says most people do not actually implement the interface to make it make sense. So they have to make ctrl-z and ctrl-shift-z do the logical linear thing which requires all sorts of craziness which is what is complicated to do correctly (e.g. without breaking user expectations).

Re: Resolving the great undo-redo quandary

#159

Post by TheRealPomax »

dahart wrote: post #142
dullcrisp wrote: post #128

Earlier quoted context omitted.

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

Hehe, sure, but there are better ways to do this, and it’s a common need. If the best thing we have is hitting undo 45 times to find something, copy it, try not to accidentally type anything and try not to accidentally lose the clipboard, then redo 45 times, then do a bunch of manual editing… now repeat the entire process for every file, when there are several involved… if that’s sufficient, then SVN is sufficient fo…

Is it though? If you really just needed part of what you had and hour ago, then there's nothing wrong with scrolling back to an hour ago, copying that one bit you needed, scrolling back some more to where you were a minute ago, and integrate it as desired?

(which, note, is not window shopping: you didn't go back to have a look and skedaddle; the past is a data store, and you're accessing that data store for productivity reasons)

Re: Resolving the great undo-redo quandary

#160

Post by crdrost »

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…

I might be understanding you poorly here...

The author is not dismissing this in the sense of saying “it's impossible and that's okay” but rather “it's possible and it never generated the ambiguity in the first place, so it needs no special logic.”

So you probably actually use undo-redo in two big ways:

1. I just pasted the wrong thing or modified the wrong file or the kid grabbed the keyboard etc, I want to quickly erase N changes.

2. I want to grab info from the past and surface it back to the present. I cut something and then lost my clipboard contents, or so. This is what you described.

The problem in the article is, basically imagine that you get the key wrong. You do your browsing thing, you are N levels back in time, but instead of Cmd-c to copy this block of code, you accidentally either Cmd-x which deletes it, or Cmd-v or Opt-c or so which overwrites it. You were trying to do (2) but now the dominant heuristic suggests to the computer that you are actually doing (1). Because in the usual implementation of undo-redo, undos push changes off the history onto a stack, redos pop changes off the stack onto the history... And any new change clears the redo stack! That stack clear is the heuristic providing the difference between (1) and (2). When the heuristic misfires, it misfires in really dangerous ways, potentially eating hours of work.

So (2) is not being dismissed as “who cares” but rather as “that's fine because our heuristic has not yet led us astray, every implementation of undo that has redo will solve obvious-(2) and obvious-(1) correctly.”

This is where I might be misunderstanding you, I am not clear if you are saying that your editor is cooler than this default interpretation in some way that does not require “redo all the way back and cut-and-paste the previous partial state”...? If so then I would have to hear more before I could know if the article’s “history is always chronological, but browsing history is different than undoing it: undoing it only happens on an edit to an old browsed copy and saves a history-rollback into the modern chronological history, rather than fussing with undo graphs or whatever” approach works that way.

Edit: actually, the article’s approach of having a browse mode solves your problem automatically in a counterintuitive way... Cut instead of copy, you will get launched out of browse-mode, then undo twice to get to the tip of your history. Counterintuitive but definitely saves some keystrokes.

Post reply on HN