Hacker News Reader

Comment by 323 | Hacker News Reader

Many times I want to undo to a previous state, but then apply again a few of the changes I just reverted, basically cherry-picking from the future (from the redo stack).

It would be interesting to be able to see all edits as individual patches/diffs that you can commit/discard individually. Like a mini automatic git inside the editor, automatic in the sense that every "edit" creates a commit, undo/redo move HEAD.

This would be entirely optional, you can continue using Undo/Redo as usual, but if you need to do a more complex history operation you can open this "git" view and operate on the edit tree directly.

Photoshop has this nice undo panel where you can see individual edits and click your way to the desired point in history:

https://www.bwillcreative.com/wp-content/uploads/2020/08/how...

One can imagine such a view in a text editor, where each entry shows a diff of what that step did.

View on HN

Use local history in any JetBrains IDE.

And with the diff panel you can easily cherry pick selected changes to apply.

Seriously. This is one of those features I forget other people don't have access to. Anything less is just uninspired.

VS Code has this feature too, it's just not known.

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...

You’re usually autosaving. So it’s not every character, but maybe every minute and lots of other logical triggers like running the file. I’ve found it works very well.

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

(But also buggy...)

This is what I thought the undo redo quandary would be. The fact that you can undo an undo seems like tablestakes to me.

In Atlassian Sourcetree you can stage the full current file, undo live changes in your editor, make different changes to your live document, and then reapply chunks of your prior changes from staging to live document (actually looks like undoing unstaged chunks).

If the changes "conflict" it might be best to use a "smart" editor that can somewhat figure out changes on a higher level.

Agreed.

When I write "foobar", delete the last three characters (so that now I have "foo", then I write a "t", I would like to be able to undo the previous deletion (giving me "footbar"), not just adding the last character.

Seems to me that would work especially well in editors that have the concept of verbs + objects, like vim's "delete until the end of the line" or "replace current word with...", but maybe it would work with all kinds of editors?

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

  foo<<<bar===t>>>

I’m kidding, but only a bit: the (in hindsight, reasonable) lesson of the Pijul paper[1] is that if you want to do the most general merge and (therefore) avoid any arbitrary choices, you’re forced to extend your model from consistent files as sequences to files potentially containing conflicts as DAGs (or something even more complicated if you have data more complex than a single flat sequence or edits other than insertions). Or you can very carefully make a consistent set of arbitrary choices, like implementations of operational transformation usually do.

[1] https://doi.org/10.1016/j.entcs.2013.09.018

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.

Reply on news.ycombinator.com