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

231–240 of 247 posts

Re: Resolving the great undo-redo quandary

#231

Post by _huayra_ »

randlet wrote: post #104
_huayra_ wrote: post #98

Earlier quoted context omitted.

Well if you want to return to Emacs, I can attest as a former long-time vim user that the emulation layers for vim modes in Emacs are fantastic! They're really the only good part of vim, as the configuration language was always a bit less desirable than elisp, imo.

I've tried in past but always found the vim modes to be a bit lacking. My last attempt was probably 6 or 7 years ago though so maybe worth another shot!

There is a very opinionated and batteries-included "Vim-y" Emacs called Doom [0]. A decent way to approach this if you don't want to start writing elisp outta the gate to have fancy editor features is to learn enough of the Doom config to tweak it to your liking, then add some elisp customization in as needed. I personally use this approach, usually cribbing config and elisp tweaks from the top contributors' configs.

The Evil layer that Doom and most everyone seems to use for Vim modes works really well, and has a lot of ways to tweak things (e.g. changing `j` to `gj` for going through line breaks in normal mode; I forgot what that setting is called...).

There is something to be said by bootstrapping your config entirely from scratch instead of using a "config framework" like Doom, but that can be too daunting and end up preventing one from trying things out.

[0] https://github.com/doomemacs/doomemacs

Re: Resolving the great undo-redo quandary

#232

Post by vintermann »

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

Earlier quoted context omitted.

After 10 years he might even be as fast as with a non-modal editor.

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 god with modern CUA-derived interfaces too (or with Emacs) if you'd put similar effort into it.

Re: Resolving the great undo-redo quandary

#235

Post by Fil101 »

dahart wrote: post #121

> Second of all, there's no need to include "window shopping" in our recorded history; this is when you undo a ways, take a look around, then skedaddle out of there back to "the present" without changing anything. This is just a matter of moving information back and forth from undo-stack to redo-stack. Usually the whole reason I might undo for a while is to get back part of something I was working on and merge it int…

No post body was provided.

Re: Resolving the great undo-redo quandary

#236

Post by hddqsb »

joemi wrote: post #197
dahart wrote: post #121

> Second of all, there's no need to include "window shopping" in our recorded history; this is when you undo a ways, take a look around, then skedaddle out of there back to "the present" without changing anything. This is just a matter of moving information back and forth from undo-stack to redo-stack. Usually the whole reason I might undo for a while is to get back part of something I was working on and merge it int…

The author isn't dismissing "window shopping". They're just dismissing the need to keep track of the "window shopping" in the history, since you're not changing anything in the history. If you have state1, edit it and get state2, edit that and get state3, then go back to state2 and copy something and then go forward again to state3 to paste that something, why should the history from state3 (in reverse chronological…

This. To elaborate, the problem is that without the "window shopping" optimisation, you are forced to repeat all your "window shopping" excursions twice every time you want to go a little further back in time.

To illustrate how horrible this is, I'll continue the example: When you paste that something, you get state4. Suppose you then wanted to copy something from state1. Without the "window shopping" optimisation, you would have to go state4,state3,state2,state3,state2,state1, copy, state2,state3,state2,state3,state4, paste.

If you then wanted to copy something from state0, it would take 34 steps!

Re: Resolving the great undo-redo quandary

#237

Post by hddqsb »

This sounds very similar to Emacs' undo history, except Emacs doesn't implement the "window shopping" optimisation. Instead, Emacs has a command `undo-only` which is similar to `undo` except it will skip over undo-redo chains.

> Thus you can use up all available memory in approx. 64 quick steps by: ...

I disagree. If the editor uses a very basic implementation, then "Undo to beginning" would probably require the user to perform multiple undo steps, in which case the memory usage would be linear in the number of steps rather than exponential. If the editor supports "Undo to beginning" as a single operation, then it would be reasonable to expect a more sophisticated implementation that does it efficiently -- memory usage can be reduced by sharing the repeated sections of the undo/redo stacks, and it is possible to efficiently skip over undo-redo sequences by recording which states are identical. Exponential memory usage would be indicative of a lazy programmer rather than a fundamental issue with the GRUQ-orithm :)

Re: Resolving the great undo-redo quandary

#238

Post by hddqsb »

nine_k wrote: post #217
bitslayer wrote: post #114

Earlier quoted context omitted.

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.

(But also buggy...)

Re: Resolving the great undo-redo quandary

#239

Post by kzrdude »

pjungwir wrote: post #188
samtheprogram wrote: post #183

Earlier quoted context omitted.

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

That's neat, and a missing part of my vimrc - making sure the directories I use exist. Since I use .cache and exclude those from backups, it's actually bit me.

I've added this thanks to you:

   call mkdir($HOME . "/.cache/vim/", "p", 0o700)
I think this avoids using the conditionals, by just using "p".

Re: Resolving the great undo-redo quandary

#240

Post by roryokane »

lolinder wrote: post #223
Waterluvian wrote: post #221

I want two things before retirement: 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. 2. visual clipboard with history. I don’t want to be surprised when I paste something. Show me. Also let me have more than one item in the clipboard. Now I know some of you veterans will say, “there’s a plug-in for this! You just need to do these things…” no no no. I want this mainstream. Why…

> 1. visual undo/redo. I don’t want to be surprised when I perform either command. Show me. I'm having a hard time imagining an implementation of this feature that would be faster than "undo, check what happened, redo if undesired". I can see a need to explore the whole history (JetBrains IDEs have the local history), but what benefit do you see from previewing a single step? > 2. visual clipboard with history. I don…

For browsable clipboard history on macOS, I recommend LaunchBar (https://www.obdev.at/products/launchbar/; docs at https://www.obdev.at/resources/launchbar/help/ClipboardHisto...). I used to use the Clipboard Plugin of the free and open source app Quicksilver (https://qsapp.com/), which worked fine but was slightly less streamlined. Some people prefer Alfred (https://www.alfredapp.com/help/features/clipboard/).
Post reply on HN