Howdy,

I see there’s a method to inspect a view’s command history (to e.g. produce an undo/redo list) but I don’t see a straightforward way to modify said history.

1. Does one already exist?
2. If not, as a workaround, could one be simulated by resetting the view/buffer to some initial state and then “replaying” the history?
3. Alternatively, is there a way to run a command on a view/buffer in a way that it sets a history entry but doesn’t execute the corresponding action?

Thank you,
Alvaro

2 would probably work, but you can’t change the buffer without the view updating. That is, you’d get the flicker of changing text as you mucked with the history.

Thanks—a bit of experimenting in that direction has been encouraging. Still, not being very familiar with the view’s event system, I’m wondering:

1. Would performing the “replay” in an async handler rather than blocking be advisable, in order to mitigate some of the issues involved?
2. Besides the view’s command_history (of explicit mutations to the buffer) what other commands or events would need to be captured to recreate the complete edit (undo/redo) history? (I’m thinking of things like the cursor position or current selection, which give context to commands like “insert”)

Alvaro

That should be all you need: the command_history logs e.g. where insertions happened, I believe.
I wouldn’t try doing it async, because someone might change the buffer while you’re changing it

Generally, I found the command_history API to be very cumbersome and yielding unexpected results in quite a few cases, notably with modified_only=False. Additionally, I was able to reliably crash ST by under certain circumstances (while debugging) and only calling it with modified_only set to false would not crash in the situation.

So yeah, view.command_history is “probably” the way to go, but it’s not a paved way and a limited one. Another idea is to use on_*_command hooks and build the history by yourself. This has the immediate advantage that you get parameters as well BUT not each command creates an undo point, and some might even create two iirc. You’ll probably end up merging information from command_history and from your own recorded history and try to get reasonable data that is similar to what ST tracks internally.

Btw, the only way to “reliably” replay a view is by invoking the “redo” command.