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

71–80 of 247 posts

Re: Resolving the great undo-redo quandary

#71

Post by kdmccormick »

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?

Nope, the author's solution is to consider the original undo (the "time travelling") to be an undo-able change in itself. No branching history. So you end up with:

  state 1
   * change A
  state 2
   * change B
  state 3
   * undo B
  state 2
   * change C (the "butterfly squashing")
  state 3a
   * undo C
  state 2
   * undo 
  state 3 (!)
   * undo B
  state 2
   * undo A
  state 1
The traditional editor would differ by putting you right at state 1 at (!), blocking your access to state 3.

Re: Resolving the great undo-redo quandary

#72

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

#73

Post by cwillu »

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.

It's more of an implementation detail that is available to users. The article's simplification is also available via :earlier and :later, with the added bonus that they can take _time_ as a parameter as well as a simple revision count. “:earlier 1h” has been handy more than once.

Re: Resolving the great undo-redo quandary

#74

Post by jasonlotito »

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.

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

Re: Resolving the great undo-redo quandary

#75

Post by jefftk »

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

Re: Resolving the great undo-redo quandary

#76

Post by cwillu »

cletus wrote: post #22

The best form of history, undo and redo I've used is on hte various Jetbrains editors. It's a feature called Local History and is insanely useful. 1. It's always on. It never requires an explicit save or commit; 2. It automatically saves any changes and timestamps them; 3. You can view the state of a file or a tree at any moment in time and then pull out that file (or tree). 4. If you do that, it becomes part of the…

> "Oh I need to unwind most of what I did in the last hour" or "I changed something I shouldn't have yesterday"

Vim's :earlier and :later can take a time parameter (i.e., 30m, 2h, 1d) which does exactly that.

Re: Resolving the great undo-redo quandary

#77

Post by kleiba »

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…

> This is exactly how Emacs works!

...and has been since forever. Thus I don't understand what the fuss is?!

Re: Resolving the great undo-redo quandary

#78

Post by samatman »

There's an interesting parallel here: the system proposed in the post is concatenative, and the undo tree style is, well, a tree. Sort of a Forth v. Lisp thing.

Here the big disadvantage of Forth, the implicit stack state, is less obviously balanced by something good. The UX of undo trees could certainly use improvement, it would be great if undo/redo behaved as expected, but any pivot point would automatically pop up the tree view. Then there's cherry-picking, but I have a solution to that.

This is in fact the thing I want most from an editor: select a region and then undo/redo changes only in that region. Search and replace tends to work this way, but I've never seen it in an undo/redo system.

How many times have you modified a function, broke it accidentally, and just didn't notice and made more changes? So the tests go red, you run a diff, and you see exactly what needs fixing: but you copy and paste out of the diff, because you can't just undo within the offending function.

Re: Resolving the great undo-redo quandary

#79

Post by chrisshroba »

I disagree that undo and redo are the only two actions needed to support this behavior. For example, if I’m performing the following three actions:

- insert A

- insert B

- insert C

And then I undo, I would expect to be be back at having AB. If I then undo, I would be undoing my undo and have ABC. Then undoing again would get me back to AB. And I remain in this 2-cycle.

Instead I propose the best solution is to be able to “step out” of the editing experience and see your history in a separate UI, and be able to choose a specific past version to revert to. This revert would be an atomic operation that could then be undone.

This is how most versioned consumer systems I know of work today (e.g. Google Docs, Figma, MS Office) and it feels intuitive to me as a user.

Re: Resolving the great undo-redo quandary

#80

Post by osrec »

dmix wrote: post #69
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.

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