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

191–200 of 247 posts

Re: Resolving the great undo-redo quandary

#191

Post by IshKebab »

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…

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

Re: Resolving the great undo-redo quandary

#192

Post by ray__ »

bhawks wrote: post #164

Google's internal source repository client CitC (client in the cloud) behaves this way for your entire workspace, forever. It was so freeing - every single file save, delete, move and so on was saved without user intervention. Realize that you were barking up the wrong tree for 2 days? Simply go into .snapshots and the entire workspace from before would be there. This interface composed so well with other tools you c…

I'm surprised that tools like this aren't more common (even in non-commercial settings) given the tiny amount of space that code/text takes to store.

Re: Resolving the great undo-redo quandary

#193

Post by db48x »

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…

In Anathem there were academics who spent their entire lives learning the history of academic scholarship for the express purpose of reminding everyone how often things are reinvented and preventing people from getting too excited when they have discovered something that was already known. I’m drawing a blank on their name, but it was one of the things about the book that I really enjoyed. It really helped to sell the setting, where the scientific method has been known and used continuously for 5,000 years or more.

Re: Resolving the great undo-redo quandary

#194

Post by dahart »

TheRealPomax wrote: post #159
dahart wrote: post #142

Earlier quoted context omitted.

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

I feel like it is, so I’m not sure what you’re asking. It’s sometimes error prone depending on editor, and sometimes a lengthy and manual hassle to undo many times & copy old state, and then to merge if it’s not a single contiguous block and not a single file. It’s way easier to do what I’m talking about if I’ve committed changes in git every 5 minutes, but I don’t always do that in advance (most people don’t), and therefore could be nice to have a non-linear undo UI that addresses the workflow example I’m talking about, which happens to be a common reason that people even think about what happens in multiple undo-redo scenarios in the first place. What’s wrong with pointing out that 1- we can make better tools if we want, and 2- linear undo/redo doesn’t solve the whole problem?

Re: Resolving the great undo-redo quandary

#195

Post by dahart »

crdrost wrote: post #160
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…

Fundamentally, the example I’m bringing up requires a tree structure conceptually, mixing some older history with some newer history. The solution in the article doesn’t address this, and it seems to dismiss the need for this use case, but I’m saying the whole reason I get into a situation where knowing how undo and redo work, and when I might care about whether typing after redo will lose history, is because I’m trying to merge old state with recent edits. I want both changes, not just one or the other.

Re: Resolving the great undo-redo quandary

#196

Post by ilyt »

randlet wrote: post #96
onedognight wrote: post #24

Earlier quoted context omitted.

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.

Yes! Having regional undo is super useful sometimes. I switched from emacs to vim a long time ago, but still miss this feature (although not enough to go searching to find an equivalent vim plug in I guess). Lazy web?

I switched from Emacs to IDEA because IDE features are frankly unrivalled but I still think Emacs does the text editing part plainly better

Re: Resolving the great undo-redo quandary

#197

Post by joemi »

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…

The author isn't dismissing "window shopping". They're just dismissing the need to keep track of the "window shopping" in the history, since you're not changing anything in the history.

If you have state1, edit it and get state2, edit that and get state3, then go back to state2 and copy something and then go forward again to state3 to paste that something, why should the history from state3 (in reverse chronological order) then be [state2,state3,state2,state1] when it could just be [state2,state1]? This is what the author claims, and it makes sense to be. If I undo, don't make any changes, then redo, I don't want that undo-redo to then be part of the undo history.

Re: Resolving the great undo-redo quandary

#198

Post by pencilguin »

It always astonishes me that undo, redo, and auto-save are implemented without relying on a logging mechanism akin to databases' "write-ahead logs".

To me the main problem of maintaining "redo" actions is of identifying them. They are unnamed, and presenting and recognizing an alteration is hard.

Re: Resolving the great undo-redo quandary

#199

Post by jorams »

xixixao wrote: post #50
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…

You can use “cut” instead of “delete” and clipboard with history tracking, for example Alfred on macOS. Then you cut, do some changes, and later on realize you wanted something from the cut code, bring out the clipboard history and fish out what you need.

Emacs does this by default. Anything you delete ends up in the "kill ring", and you can cycle through that when pasting ("yanking") something. Packages like Consult[1] provide version of the yank-pop command that, instead of cycling through the kill ring, make it searchable.

[1]: https://github.com/minad/consult

Re: Resolving the great undo-redo quandary

#200

Post by marcinreal »

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.

Make sure to check the value of `undo-limit`, as the low default value greatly (and needlessly, on modern machines) nerfs undo. It also applies to extensions like undo-tree and vundo I believe.

> undo-limit is a variable defined in ‘C source code’.

> Its value is 10000000

> Original value was 160000

Speaking of extensions, I find undo-tree pretty buggy. I might be one of a dozen people who actually love the default undo/redo mechanism.

Post reply on HN