Live data from Hacker News

Resolving the great undo-redo quandary

github.com

201–210 of 247 posts

Re: Resolving the great undo-redo quandary

#201
My biggest gripe with undo is in cases where it's unclear what undo will do if anything, and the action is file or email related without a clean redo option.

Thunderbird - oops I just keymashed and did a bunch of random shortcuts. OK great I can Undo infinitely with no indication of what emails are being moved or undeleted, etc.

Windows Explorer, Dolphin etc - undo can be pretty opaque unless you already know what it is that is being undone. And there isn't a redo!

> Of course that tree requires a navigation system for users to pick their way back through the undo-redo history, leading to all sorts of complicated user interfacery that nobody has time to deal with.

I would LOVE the complicated user interfacery to be in all applications to show at least the list of actions! Image editors are great at this.

Re: Resolving the great undo-redo quandary

#202
post #20

Earlier quoted context omitted.

Should it be “footbar”? Or “foobart”? I could see a case being made for either.

Depends on where the cursor is when you press redo, because it was originally inserted at the cursor position.

I would definitely not want the behaviour of undo/redo to depend on the current position of the cursor; that’s what paste is for.

Re: Resolving the great undo-redo quandary

#205
TL;DR

So much cognitive load.

Just configure Vim to put everything you delete in your clipboard and use a clipboard manager like diodon[1] with 1000 items.

Of course works also outside of Vim, you just have to copy the part you might want to reuse before deleting/modifying.

[1]https://github.com/diodon-dev/diodon

Re: Resolving the great undo-redo quandary

#206
post #125

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?

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.

Re: Resolving the great undo-redo quandary

#207
post #153
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

Visual Studio Code offers something similar in the timeline view. It's not as fine-grained, but still can be a life saver.

Re: Resolving the great undo-redo quandary

#208

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.

Additionally, emacs will filter undo/redo’s to changes within a region. If you select a region (no new command to learn) and use undo/redo, it will only perform those that affect text completely within the region. This is a superpower that delights me each time use it.

That region based undo is fantastic and has saved my bacon so many times! I really wish more apps had it, though I shudder to think of the implementation complexity.

Re: Resolving the great undo-redo quandary

#209

Earlier quoted context omitted.

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

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?
Post reply on HN