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

241–247 of 247 posts

Re: Resolving the great undo-redo quandary

#241

Post by edub »

323 wrote: post #103
alisonatwork wrote: post #99

Earlier quoted context omitted.

Fantastic! Thank you so much. I think it's a fairly common situation that people using programming tools (VS Code, git, vim etc) can go for years without realizing there is a built-in feature that can solve exactly a problem they always struggled to solve. I'm not sure how to surface that sort of functionality in the tool, but I'm glad HN is here to point it out. One similarly cool thing I learned in a recent comment…

It helps to read the VS Code monthly update release notes, it takes about 3 min, but you'll be aware of all new features they introduce.

You are a faster reader than me. The October update has around 4,700 words plus plenty of images to digest. I understand you likely mean to review the highlights, but a non-trivial amount of information is in each months update. And if you haven't been keeping up for the past 6 years, it isn't easy to catch up now. Not to mention the breadth of the marketplace.

Re: Resolving the great undo-redo quandary

#242

Post by quag »

lelanthran wrote: post #215
quag wrote: post #129

Earlier quoted context omitted.

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.

When set undofile is combined with :earlier and :later being used in place of undo and redo I think vim behaves as the author describes.

Re: Resolving the great undo-redo quandary

#243

Post by Sateeshm »

This happens to me frequently both in code editing and designing in Adobe suite, needing some of the redo changes after a series of undos. I usually just cut/copy the the parts i want to keep before doing the undos to get to a previous state and paste them back in. Works pretty well.

Re: Resolving the great undo-redo quandary

#245

Post by stolsvik »

somishere wrote: post #213
remram wrote: post #178

Earlier quoted context omitted.

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.

Not with this new algorithm.

Re: Resolving the great undo-redo quandary

#246

Post by ejstronge »

vintermann wrote: post #232
Ar-Curunir wrote: post #173

Earlier quoted context omitted.

Every non-modal editor I’ve used is significantly slower at editing text than Vim

We have been through this argument many times. Here's Tog at Apple in 1989: https://www.asktog.com/TOI/toi06KeyboardVMouse1.html And even then, it was old news. There was behavioural research in the 70s, the same kind that was used for designing cockpits (and which saved lives), showing that modal interfaces were undesirable. It can well be that you're a god with vim. But odds are, then, that you could have been a go…

Supposedly this article has been mis-cited of late and the keyboard shortcuts / mouse shortcuts of yore are distinct from what we have today. I can't find recent links but I'll offer the general advice that words used in the 70s do not necessarily have the same connotations they carry today.

EDIT: here's an HN discussion https://news.ycombinator.com/item?id=28067729

Post reply on HN