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

211–220 of 247 posts

Re: Resolving the great undo-redo quandary

#211

Post by vidarh »

dahart wrote: post #194
TheRealPomax wrote: post #159

Earlier quoted context omitted.

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

Doesn't sound like linear undo/redo is the problem, but rather ability to navigate it. Timestamp the actions and you could offer "undo to 1h ago". Or you could allow searching the undo history.

But I may be having a hard time understanding why you need this as your description just does not fit my typical workflow.

Re: Resolving the great undo-redo quandary

#212

Post by somishere »

dahart wrote: post #195
crdrost wrote: post #160

Earlier quoted context omitted.

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

Have to disagree here. "History mix" is a super common use case for me, as is a "clip slip" scenario - where I fumble and erase the future.

The technique as described works fine for this. I use it in the terminal all the time (an interface where state is saved on execution rather than keystroke). You go up through the history, copy the part of the command you need and head back to the present to use it.

I think it just comes down to the point at which state is modified. I wouldn't expect an implementation to modify state just by viewing the history, only by editing it. Suffice it to say your use case is fine.

Edit: tho, reading some of your other comments I agree that a better interface for this use case (e.g. a "revert to last meaningful edit" action) would be useful. Tho its slightly tangential to the discussion.

Re: Resolving the great undo-redo quandary

#213

Post by somishere »

remram wrote: post #178
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…

In the proposed article, it sounds like if you accidentally typed anything you would have to hit "undo" twice instead of "redo" N times to get back. Still seems confusing.

But if you accidentally type something now you can't just hit redo N times to get back. It's gone.

Re: Resolving the great undo-redo quandary

#214

Post by mhb »

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

Unbelievably, Solidworks does not even have undo for some things and undo/redo are terribly broken.

Re: Resolving the great undo-redo quandary

#215

Post by lelanthran »

quag wrote: post #129
lelanthran wrote: post #94

Earlier quoted context omitted.

Yes, but GP wanted something that would just keep all deleted text. Sort of, anytime you delete something, that text gets stored somewhere in case, 2 hours later, you realised you wanted it.

Yes, vim’s “set undofile” will create a persistent undo file that stores all changes to the file indefinitely. You can undo changes made months ago over reboots. If you move the undo file between machines, you can undo on different computers. Undoing a change from 2 hours ago in the same editing session is the trivial use case for undofile.

But undoing is not what the original commenter wanted.

Re: Resolving the great undo-redo quandary

#217

Post by nine_k »

bitslayer wrote: post #114
spullara wrote: post #16

Earlier quoted context omitted.

Use local history in any JetBrains IDE.

I am not a JetBrains user, but it looks like that only applies to saved versions? Undo normally holds every typed change. https://www.jetbrains.com/help/idea/local-history.html#resto...

In Emacs, if you select a region of text and invoke undo, it applies only to the selected text. Very useful sometimes.

Re: Resolving the great undo-redo quandary

#219

Post by phendrenad2 »

somebodythere wrote: post #210
sharikous wrote: post #27

My way is a a ugly undo - copy - redo - paste. Not efficient, sure, but I'm used to it and it solves my problem most of the time

The main issue with this I find is a stray keystroke before you redo wiping your redo stack .

I solve this by making a git commit before diving into the undo.

Re: Resolving the great undo-redo quandary

#220

Post by phendrenad2 »

Hmm, interesting, but I would actually like a different system (and let me know if any VSCode plugins implement this!): I want TWO forms of undo, one which actually undoes my changes, and one which only shows me a ephemeral view of the code in previous states. Call it "not really undo" or "viewing history but not changing it".
Post reply on HN