Currently I can’t see of a way to store plugin state in the history plugin. It can be quite expensive - or even almost impossible if transaction purely set metadata, which isn’t available in the history events - to recompute plugin state from history events. Would it be possible to add an API to the history plugin to allow other plugins to register their state on each transaction and to be able to fish that out of a history transaction?
Undo doesn’t really just roll back to a previous state, so in general this wouldn’t be a safe thing to do.
What is your plugin doing that makes it impractical to just treat undo like a normal transaction?
I feared you might say that! It’s tracking changes and it all works very well but it sounds like there’s probably some edge case that may come and bite me from somewhere.
Basically, when “adding” a deleted range I essentially filter the deletion and set some state somewhere but when an undo transaction comes through there’s no information on what changed. Basically, given the undo plugin only gives you the state of the document, I don’t think I have enough information to derive the users intentions given I’m filtering some of the transactions.
Storing state on the document is, as I say, working fine on the doc attrs but there will probably be a day where a plugin does something unexpected and all bets are off!