Idempotence of null operations

[countvajhula]

Certain commands insert extra characters that are useful and commonly desired when making changes. But if the command was executed accidentally or if the user changed their mind, we want to ensure that canceling the command restores the buffer to its original state. This ensures that null commands are idempotent, providing a more cohesive experience. The following commands should be reviewed in this connection:

(I)nsert-before
(A)ppend-after
(w)rap
(W)rap

and possibly even:
(o)pen-below
(O)pen-above
(c)hange
(C)hange-remaining
(s)ubstitute (i.e. replace)

[yuki-tsubaki]

By What do you mean by "cancelling" a command in this context?

[countvajhula]

Canceling as in:

If you press I, it inserts a space before the symex and enters insert state. If you then hit Escape (or however you return to Symex mode) without making any changes, it should ideally "undo" that space insertion, since, presumably, you changed your mind.

Likewise, o and O insert newlines, like in Evil. But in Symex, if that's all you wanted to do, you could use >, <, C-> and C-<. So in these cases, too, we could infer that you changed your mind, and we should cancel that newline insertion.

But actually applying and undoing these changes seems heavyweight and bug-prone, as it pollutes the undo history. It would be preferable if, e.g., I, could just "virtually" insert a space and put you in insert mode, and only actually do that if you type more keys.

But I can't think of a good way to do this. For example, if we don't actually go into Insert mode upon I, then how would it even know if an "Escape" like key has been pressed which would return to Symex mode, thus canceling the operation? It seems that it would need to actually be in Insert mode in order to have access to that keybinding, and maybe only the inserted space would be "virtual". Maybe overlays could be used for this?

There might be some notion of an undo "canary" that we could use, where we would set a canary and then actually insert, and actually undo up to the canary and then delete that part of the undo stack. Of course, mutating the undo stack seems risky, but maybe it could be done carefully.

[yuki-tsubaki]

Ok that is what I was guessing but when I was trying it and didn't notice any of them actually implementing it (I saw it was supposedly planned for 2.0) I started wondering if there was like a cancelling function or something that I didn't know about or if it was just leaving the symex editing mode.

Regardless, I think it probably could be done with overlays but probably isn't worth for trying to universally apply. You also run into the problem of how far back do users consider something as part of the command. It might be cool if an editor kept track of your whole graph of changes and then upon leaving symex state decided if those changes were material or if the buffer should be reverted to the original state. But I think the actual practical benefits of such an approach are minimal (it saves what? reentering and pressing delete?) while the complexity of a proper implementation (that interacts properly with external commands) would be immense and out of scope of this project.

In practice, for all of these main cases pressing undo or having an auto reformat button that removes trailing spaces would probably be best.

---

But then I thought more...

---

If we wanted these things to happen automatically maybe you could track a symex--insert-enter-command (that is checked on exit if it should be handled) and some how keep track of weather any other interactive commands have been run after that (e.g. hook on post command hook that removes itself and sets some symex--done-nothing variable to nil after being executed). Then if symex--insert-enter-command is one that should be idempotent and symex--done-nothing is still nil then it automatically undoes it (using whatever method appropriate).

Ok not that I thought that through it doesn't sound that hard so ig it could be reasonable.

Maybe you can just have it automatically call undo after the exit and call it good?

[yuki-tsubaki]

This idea at least sounds more reasonable than effectively caching all user edits, showing them as an overlay, and then merging if they are deemed significant.

Or at least I know how to implement it whereas I don't think I know how I would do the overlay method (and probably more important, I don't know that whatever way could be used to implement the overlay cache method would play nicely with other packages).