I am continually irritated by this behavior.
Yes, I do want to undo one operation. If I need to go fast and have little regard for correctness I can hold the button down.
Don't make me play the game where I hit undo, it undoes the whole sentence (or several), so I hit redo to bring it all back, and then I have to click backspace 5 times to get to where I wanted. Worse when I'm using multiple cursors and doing operations of different lengths to each line.
To keep things short: Whenever you want to insert some text you need to switch to Insert mode. When you're done you Esc out back to Normal mode. Undo will undo everything you did inside the last Insert.
> To keep things short: Whenever you want to insert some text you need to switch to Insert mode. When you're done you Esc out back to Normal mode. Undo will undo everything you did inside the last Insert.
That's a more extreme version of the behavior I'm objecting to. Why would I prefer that?
Undo is for undoing an action, like inserting a bunch of text.
If you want to delete one character at a time backwards... use the backspace key?
Put something in the wrong place (probably via pasting, but it's not always clear to a screen editor if you pasted or just typed quickly)
This is worse when I'm using multiple cursors, which is usually me manually cleaning up some data.
You can imagine a lot of quality of life improvements built on top of that depending on your application: eg if the user holds granular undo and there are many combinable operations (eg the user drew a single stroke that is represented by hundreds of single pixel additions), you may snap to a single coarse undo. Or you can offer a visualization of the underlying operations and what they map to, etc.
(see sibling comment by ‘reificator)
That said, for technical applications, I think it makes sense to expose as much of your features as possible in terms of composable, atomic units and operations.
If Cmd-Z maps to a black box “undo” command, then anything on top of that will seem like it comes at an interface complexity cost.
If, however, Cmd-Z is a configurable shortcut like any other that, by default, happens to send a “undo 1 user operation” message to a “history” module, that’s a different story. Now your users can modify it to be “undo one high level operation” instead, or “undo all consecutive operations that are the same in kind”. Or perhaps they want Cmd-Z to undo the last discrete operation, and Cmd-Alt-Z to undo the last logical operation. Or maybe there’s a strong temporal dimension to their work and they want the undo logic to take that into account.
Likely not the kind of thing you’d want for a mobile photo sharing app meant for a wide audience; but maybe the kind of thing you’d want for a complex, specialized data processing tool on the desktop.
I've dealt with this issue in various tools and level editors a few times. It can be annoying. The fundamental problem is that if your tool has undo (which it should), the cleanest way to architect it is such that every state change goes through undoable operations.
But that means that even in the "middle" of an operation like dragging something, or painting a long meandering line, you need to be creating and processing individual undoable steps so that the user can see the operation as it proceeds.
But once the operation completes, if they undo, they (usually) want to undo the whole batch of them, not each tiny step. A closer-to-home example of this for most programmers is their text editor. Type a sentence quickly and then hit undo. You don't want that to just undo literally the last character.
There are two ways I know to handle this:
1. If memory is less of a concern, I keep the series of individual undoable steps and then wrap them up in a single "multi-step" undoable operation. Then, in the main undo queue, replace them with that wrapper so that they are all processed as a single operation. When you undo the wrapper, it just undoes all of its child steps in reverse order.
2. If memory is more of a concern, I add support for collapsing a series of undoable operations into a new larger one that can represent the entire aggregate change more efficiently. This is more work because you need to write separate code for each kind of operation that can be batched this way.