Improvement: Set an undo point every time the user stops typing for a set time

[RustyStriker]

Instead of only saving an undo point when switching between insert and normal modes, we can add an undo point if the user is in insert mode and didn't type anything for a per-determined amount of time.

This improvement/feature will solve the "issue" of not switching back to normal enough then when you undo half your progress is deleted

[archseer]

I'd prefer to manually commit via C-s (currently unimplemented, should be as easy as calling doc.append_changes_to_history()). It's not quite the same, but it allows me to be precise in what a single undo unit is (vs having a lot of undo units simply because I paused to think while typing out my change)

[RustyStriker]

It can be enabled/disabled in config files i guess, but this improvement issue is a follow up to a conversation in the matrix channel, about the fact that it is easier to click multiple times u then rewrite half the code you wrote in a single "run".

[RustyStriker]

If it is ok to implement(the improvement is welcomed under a config variable) i would like to tackle it(tho i will require some pointers for where i need to add/modify stuff)

[dannasessha]

Agree, having more undo points to work with is preferrable to having too few.

Part of what's great, to me, about undo is I'm not thinking about it until it's time to undo. I don't want to build in 'set undo point' to my regular work flow (already, working with saving the buffer or even git is like his, a manual setting of state), I'd rather there just be a trail of states I can access quickly by tapping the same key over and over again.

I can see the point of a user who wants to set undo points by stopping their normal workflow to create them, but I feel like this is exceptional, and could be addressed with a configuration option.

[tgross35]

For me, I would like undo points to be set during any of the following events:

1. Cursor is moved
2. A word is completed (whitespace or other nonword character is entered)
3. LSP autocomplete is used
4. EIther of the above haven't happened but a timeout is reached

Reasoning:

1. Usually moving the cursor around indicates some end of some small unit of work. It is pretty rare to jump to a separate section, start typing there, and then want to undo both the new and old sections in one go
2. Usually changing word boundaries is a minimal unit of work - this would also mirror how w and b move around
3. This one bugs me: while moving around, I often somehow accidentally enter the LSP selection dialog and select a new value on something I didn't mean to change. Enter u for undo - and whatever I was working on just disappeared! Maybe there is a better way to avoid this... (edit: I see this mentioned in the discussion after Make undo less agressive #7643 (comment) was closed)
4. Something like a 5s timeout would be reasonable as a catch all

I'd prefer to manually commit via C-s (currently unimplemented, should be as easy as calling doc.append_changes_to_history()). It's not quite the same, but it allows me to be precise in what a single undo unit is (vs having a lot of undo units simply because I paused to think while typing out my change)

Something like this sounds awesome, but I think it would be best in addition to the standard undo. Document history could probably store both with a flag to say whether it was automatic or manual, u would rewind to the next back point (automatic or manual), and another combination would rewind to the next back manual commit point. Maybe even a history picker (space-c?) could show the manual commit points?

edit: seems like that idea exists, #1075

[pascalkuthe]

@archseer has made has stance on this one clear (and I agree), C-s was implemented quite a while ago.

I don't think we will change the behavior here (wit the exception of your third point but that was merged a while ago). Maybe in the more distant future you could write a plugin that calls c-s on these events. I don't see us supporting it in core