Undo behaviour

[sidju]

There is some debate over undo behaviours. The options (I currently know of) are:

• "simple" undo, where all redo potential is lost when you perform an action
• "tree" redo, where every action after you have undone creates a new branch
• "revert" undo, where the undo is an undoable action (see here)

Aside from simple (which is currently imlemented) the behaviours enable accessing every state the application has been in during this session.

I don't have strong opinions, if someone is gifted with such please opine and/or share PRs here.

[sidju]

To make matters worse, there are considerations about state changes that should occur upon undo or redo.

• Should the selection be set to the lines changed by the undo/redo? It requires more state tracking, but also makes it easier to see what you did.

• Should the undo/redo commands print what commands they undid/redid? It would alleviate the need for selection changes, but also be nice on its own. Would it need a config flag to enable/disable?

• Should the buffer be considered saved if you save it, delete a line and undo that deletion? It is simpler for it to be unsaved in that case, but is it confusing?

[sidju]

Now that I am working on undo/saved behaviour the "revert" style of undo seems quite attractive, but then without treating undo/redo as actions unless you mutate afterwards (to allow exploring the undo history).
The buffer can then track the undo index where it was last saved, and undoing to that point without mutation is considered saved. Upon mutation you then create a revert snapshot (redundant with the otherwise saved snapshot, changing saved index to the revert snapshot's index) and then create a snapshot for the mutated buffer.
(Thanks to updating the changed index to the revert snapshot's index you can thereafter undo the mutation and return to a state considered saved. Tracking of multiple saved points in history would be possible, but I think this is equally intuitive and less complex to code.)

The reason "revert" undo is nice with this is that the undo history is strictly growing, so there is no risk of re-using the undo index marked as saved.

[sidju]

The last solution mentioned above has now been both chosen and implemented. Refer to the code for History for the implementation of it (which may well be more readable than the convoluted mess of an explanation above).

If you have any issues with this, complain in a new issue.