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

31–40 of 247 posts

Re: Resolving the great undo-redo quandary

#31

Post by alisonatwork »

323 wrote: post #23
cletus wrote: post #22

The best form of history, undo and redo I've used is on hte various Jetbrains editors. It's a feature called Local History and is insanely useful. 1. It's always on. It never requires an explicit save or commit; 2. It automatically saves any changes and timestamps them; 3. You can view the state of a file or a tree at any moment in time and then pull out that file (or tree). 4. If you do that, it becomes part of the…

VS Code has that feature too, but only for individual files.

I wish VS Code would expand on that feature, coming from IntelliJ. It's really annoying that you need to type the name of the file you want to see the local history of, even when it's the currently active file in the editor. There should be a sidebar widget for it that's active for whatever the current file is.

The cool thing with IntelliJ is if you accidentally deleted a file you can just touch a blank version of the file and the history comes back. Not sure if VS Code does that yet.

Re: Resolving the great undo-redo quandary

#32

Post by sulam »

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.

He literally says why at the top of the post. People find it too complicated.

Re: Resolving the great undo-redo quandary

#35

Post by andybak »

asciimov wrote: post #7

> No, there is no undo "tree"[...] This is still a tree, it's just implemented in an array.

Wll, it's a tree that is collapsed into an array - which makes it an array to all intents and purposes.

The point is that the "tree-ness" is never exposed to the user. This is the problem OP is claiming to have solved - the cognitive burden that the tree solution introduces.

Re: Resolving the great undo-redo quandary

#36

Post by quartz »

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 state while making sure not to accidentally execute any inputs which would burn down the redo stack.

Re: Resolving the great undo-redo quandary

#37

Post by vitiral »

adrianmsmith wrote: post #28
Veuxdo wrote: post #8

Sounds like the Braid version of undo-redo.

Could you elaborate or provide a link? I haven't heard of the "Braid version of undo-redo" before.

Braid is a game about time travel.

This is not like Braid at all, since the game works by "overwriting" your past actions (with a few other mechanics).

The Braid editor would be like "Normal" undo except a ghost cursor continues to make the edits you just undid. Would be a hilarious April fool's feature.

Re: Resolving the great undo-redo quandary

#38

Post by andybak »

gandalfff wrote: post #10

Alternatively, use Vim undotree: https://github.com/mbbill/undotree

I found the article interesting because it's an approach that I could apply to tools other than text editors - it explains the general concept. I wouldn't have discovered it if someone just posted a link to a Vim add-on.

Re: Resolving the great undo-redo quandary

#39

Post by Chris2048 »

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.

Sounds like this solution would best be implemented with an undo-tree, but also a linear history mapping with pointers to that tree - the linear history would just log movement within the tree over time e.g. undo-redo would just be a backwards-forwards movement.

Re: Resolving the great undo-redo quandary

#40

Post by twodave »

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

Honestly IMO it's a bit better--often times I find myself wanting neither _this_ nor _that_, but some of each. I get to a point in a function where I realize changes I made elsewhere are no longer needed, but I want to keep my function the same. So I usually just copy the function (and paste it someplace so I don't for real lose it), undo everything, then just splice the function back in how I want it.
Post reply on HN