Make undo less agressive

[JakeEhrlich]

Undo is far far more aggressive in helix than it is in vim. I keep loosing minutes of work to it because it undoes too much and then I fat finger something and can't redo which feels awful. A common case is that it undoes stuff and then I mussel memory "r" to undo the undo and then I can't go back. Can we make it less aggressive by default and/or can we provide a config option to control how aggressive it is?

The argument for matching vim or neovim's level of aggressiveness by default is to help with conversion but is just a suggestion.

[pascalkuthe]

duplicate of #1583 and #1142 generally we aren't interested in changing the way undo works. Every edit creates its own undo commit. All edits in insert mode only create a single commit so you don't have to spam undo a bunch of times. This is on purpose.

However, I am confused by your comparison to vim/nvim here since they behave exactly the same.

I fat finger something and can't redo which feels awful.

Helix (like vim) has an internal undo history so your edits are never truly lost. You can use :earlier and :later to restore edits. We want to add an undo tree eventually (potentially as a picker) see #1075

[omentic]

There is also a commit_undo_checkpoint command that you can bind to.

[JakeSiFive]

Ok so I decided to dig a bit here. So the specific behavior that I'm observing that seems unintuitive to me is that I'll do something like select an lsp change (sometimes accidentally because the list will auto popup when navigating up/down in insert mode) and then when I go to press undo it undoes a bunch of stuff I didn't want to undo. Could helix add an undo commit before an lsp edit?

[pascalkuthe]

I am not necessarily opposed to saving the undo history before adding an autocompletion point it's sort of an edge-case. i think most (n)vim plugins handle this the same way.

Thoughts @the-mikedavis

[JakeSiFive]

I think the reason that I haven't noticed this as much in other editors is not because of the undo behavior but because of the auto-complete behavior actually. Specifically the fact that navigating in insert mode can trigger the auto-complete. This is less of an issue on a qwerty keeb where hjkl work well. I also use a split-ortho keyboard with colemak where hjkl are in strange places so instead I use my navigation layer which uses arrow keys. It's a bit annoying to have to escape before doing that only to have to re-inter insert mode since I already have to press a button to enter a navigation layer. I could probably solve this by creating a helix/vim layer but its not my favorite work around.

My current work around is to disable auto-completes that so that they only come up when explicitly asked for but I think I still wind up staying in insert mode a bit longer than I would when using qwerty so my undos still feel a bit more extreme than I'd like.

[pascalkuthe]

autocompletion will be fixed in the future (I have a larger change there in the work) but I also have a moonlander with colmak and still never use in insert mode (and use arrows on a navigation layer) so its mostly a habit thing. undoing a completion may still be a reasonable usecase

[the-mikedavis]

Yeah I'm interested in trying out adding an undo checkpoint before the completion edit. We need to be a little careful where we create the checkpoint so that we don't make checkpoints too aggressively (for example on every completion request or while switching between candidates). I'm seeing how d1b0335 feels locally.

[pascalkuthe]

yeah, there should only be a single checkpoint once the completion is accepted. Luckily a completion is accepted exactly once since #6594 (and all previews are always purged) so every completion that is accepted should have a single point when we can append to history