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

181–190 of 247 posts

Re: Resolving the great undo-redo quandary

#181

Post by kzrdude »

jancsika wrote: post #132
Izkata wrote: post #102

Vim has this, it's :earlier and :later https://vimtricks.com/p/vimtrick-time-travel-in-vim/ :earlier 3 – Undo the last 3 changes :earlier 5m – Go back to the state of the file 5 minutes ago :later 2 – After undoing something, redo the next 2 changes :later 1h – Travel forward through the change history 1 hour Vim also stores the tree of changes, but it's a pain to access without plugins.

What a great feature! Is the author of that feature here? If so, I want to know how they could develop such a feature and be so quiet about it. It's like someone baking a birthday cake and then dropping it down an abandoned well. Just imagine how much more productive we'd all be if Vim bros were as loud as the crypto bros over the past decade!

Another great Vim feature is persistent undo. You open a file, make modifications, save and close. You open again and the undo history is still there. You'll just have to enable that feature.. don't think it's on by default, unfortunately. Find a ~/.cache directory to store the undo history in.

Re: Resolving the great undo-redo quandary

#183

Post by samtheprogram »

kzrdude wrote: post #181
jancsika wrote: post #132

Earlier quoted context omitted.

What a great feature! Is the author of that feature here? If so, I want to know how they could develop such a feature and be so quiet about it. It's like someone baking a birthday cake and then dropping it down an abandoned well. Just imagine how much more productive we'd all be if Vim bros were as loud as the crypto bros over the past decade!

Another great Vim feature is persistent undo. You open a file, make modifications, save and close. You open again and the undo history is still there. You'll just have to enable that feature.. don't think it's on by default, unfortunately. Find a ~/.cache directory to store the undo history in.

This would make my life so much easier — constantly accidentally closing a file when I want to hold on to the undo history to redo something. Do you know the name of the feature/flag/setting?

Re: Resolving the great undo-redo quandary

#185

Post by low_tech_punk »

Wow, the article nailed the UX.

On the implementation side, I think the article implies that you might need to model the edits by Operation, rather than State? Otherwise, the cost of the undo scales O(N) of the content size, which is not viable.

It works well for Git, which models content by State, using Structural Sharing. But Git has built-in delta compression so the memory footprint is roughly O(1) per operation. I don't think implementing this on the web for a , or [contenteditable="true"] is a "minimum" effort.

Challenges I can think of:

1. DOM api exposes state, not operations. You need manual diffing

2. When applying the operations, you need to manually restore cursor positions

3. CJK language IME might inject unwanted intermediate states that must be ignored

Re: Resolving the great undo-redo quandary

#186

Post by db48x »

jerry1979 wrote: post #162
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.

Do you know a way to keep the region selected after undoing so as to continually undo within the region?

That’s the default behavior; perhaps you have customized something that changed it.

Re: Resolving the great undo-redo quandary

#187

Post by db48x »

taeric wrote: post #105
sulam wrote: post #32

Earlier quoted context omitted.

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

I confess I didn't get that the post was about emacs. Reading the intro, it sounds more like it assumes nobody ever implemented something. And then goes on to describe what sounds a lot like how emacs works.

That’s the impression I got as well, since it never mentions Emacs at all and then describes exactly how Emacs works.

Re: Resolving the great undo-redo quandary

#188

Post by pjungwir »

samtheprogram wrote: post #183
kzrdude wrote: post #181

Earlier quoted context omitted.

Another great Vim feature is persistent undo. You open a file, make modifications, save and close. You open again and the undo history is still there. You'll just have to enable that feature.. don't think it's on by default, unfortunately. Find a ~/.cache directory to store the undo history in.

This would make my life so much easier — constantly accidentally closing a file when I want to hold on to the undo history to redo something. Do you know the name of the feature/flag/setting?

This is what I have in my ~/.vimrc:

    " https://vi.stackexchange.com/questions/6/how-can-i-use-the-undofile
    if !isdirectory($HOME."/.vim")
        call mkdir($HOME."/.vim", "", 0770)
    endif
    if !isdirectory($HOME."/.vim/undo-dir")
        call mkdir($HOME."/.vim/undo-dir", "", 0700)
    endif
    set undodir=~/.vim/undo-dir
    set undofile

Re: Resolving the great undo-redo quandary

#189

Post by jonathannerat »

gpvos wrote: post #26
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.

And it is exactly why I find Emacs undo so hard to work with. But maybe I will get it now I've read this article.

See `:h undo-persistance` for that feature. In particular you want to do `set undofile` in your vim config

Re: Resolving the great undo-redo quandary

#190

Post by IshKebab »

feintruled wrote: post #154
TuringTest wrote: post #136

Earlier quoted context omitted.

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…

I get what you are saying, but I think it is confusing to refer to a 'redo' stack at all. There is only ever one stack, and you are always at the end of it. To go back through time you copy the states onto the stack (stack isn't even the right word, I guess but I'll stick with it) Consider typing the alphabet Stack: 1.a 2.ab 3.abc 4.abcd Now you 'undo' back to place 2 and type 'x'. But while you are conceptually trav…

Yeah that's the same thing and is probably how you'd actually implement it, but conceptually you can think of there being an undo and redo stack.
Post reply on HN