Hacker News Reader

Comment by unholiness | Hacker News Reader

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.

View on HN

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

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.

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")

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

Yeah that's the same thing and is probably how you'd actually implement it, but conceptually you can think of there being an undo and redo stack.

Photoshop has nonlinear history. When this option is tunred on, you can undo several times, make a change, and not lose all the states you've undid - isn't this what he's talking about?

Yeah maybe, I'd have to play around with both to see which is less annoying.

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

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.

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.

Like the GP, I also use undo as a faster delete. The key is that undo in Emacs doesn't just go one keystroke at a time. By default it will basically quash a whole chunk of similar operations and undo/redo them together:

> amalgamating-undo-limit is a variable defined in ‘simple.el’.

> Its value is 20

> The maximum number of changes to possibly amalgamate when undoing changes. The ‘undo’ command will normally consider "similar" changes (like inserting characters) to be part of the same change. This is called "amalgamating" the changes. This variable says what the maximum number of changes considered is when amalgamating. A value of 1 means that nothing is amalgamated.

There's also a hidden 10s idle timer that will insert a boundary to break up the amalgamation. So if you type, pause and think, and then start typing again, the chunked undo/redo will always stop at the point that you started typing again. Taken together, it's usually quite effective at guessing how much to delete.

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.

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.

No, Ctrl-Z Ctrl-Z still undoes the last two edits.

Basically Ctrl-Z is now "rewind" and Ctrl-Y is now "fast forward". Instead of a stack you have an append-only list. Even Ctrl-Z appends to the list. (I'm eliding the optimizations he mentions.) So if you Ctrl-Z then edit, you can still get back to the state before your Ctrl-Z.

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

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)

>every other undo

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

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.

Reply on news.ycombinator.com