4 ms·

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

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.

dmix 4y ago
True, at what point do you include the undo itself in the undo history or do you skip it entirely? Never considered that.
- osrec 4y ago
  I feel things work most intuitively if the undo/redo functions simply navigate the history, but do not themselves form part of the history.
  - unholiness 4y ago
    That's how every other undo works. The whole GRUQ is caused by undos not themselves forming a part of history...
    - TuringTest 4y ago
      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)
    - hackmiester 4y ago
      >every other undo Ahhhhh, some time you should try a little app called Adobe Photoshop.
  - kqr 4y ago
    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.
    - dmix 4y ago
      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.
jefftk 4y ago
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
- unholiness 4y ago
  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.
  - jefftk 4y ago
    How is undo a faster delete?
    - TuringTest 4y ago
      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.
    - a_e_k 4y ago
      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.
ctrlmeta 4y ago
> 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.
IshKebab 4y ago
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.
- TuringTest 4y ago
  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")
  - feintruled 4y ago
    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...
rando14775 4y ago
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).
pjungwir 4y ago
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.
jrmg 4y ago
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.

dmix 4y ago

True, at what point do you include the undo itself in the undo history or do you skip it entirely? Never considered that.

osrec 4y ago
I feel things work most intuitively if the undo/redo functions simply navigate the history, but do not themselves form part of the history.
- unholiness 4y ago
  That's how every other undo works. The whole GRUQ is caused by undos not themselves forming a part of history...
  - TuringTest 4y ago
    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)
  - hackmiester 4y ago
    >every other undo Ahhhhh, some time you should try a little app called Adobe Photoshop.
- kqr 4y ago
  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.
  - dmix 4y ago
    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.

jefftk 4y ago

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

unholiness 4y ago
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.
- jefftk 4y ago
  How is undo a faster delete?
  - TuringTest 4y ago
    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.
  - a_e_k 4y ago
    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.

ctrlmeta 4y ago

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

IshKebab 4y ago

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.

TuringTest 4y ago
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")
- feintruled 4y ago
  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...

rando14775 4y ago

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

pjungwir 4y ago

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.

jrmg 4y ago

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.