I have a plugin that appends transactions closely related to the content e.g. marking some text conditionally based on what was entered.
In this case, I want to combine that transaction with the one being appended in the history, such that when the user does an undo, the mark is removed and the text. Right now there’s no way I can tell the history plugin that I want to merge these two and it leads to janky undo behavior.
To extend this point, while appendedTransactions don’t cause there own undo step, they still separate every initial transaction into a separate history event. So undoing deletes one character at a time. It sill may be useful to flag certain edits as irrelevent when it comes to comparing the proximity of edits for the following undo event. Is this something you’d consider a PR for
That’s not a trivial fix, because ideally you’d want to use the old prevMap value to compare against, but since the appended transaction may have made changes, that no longer points into the current document, and there’s currently no functionality to map step maps in the library.
Not terribly difficult. Since this map is being used in a limited way, only to check for adjacency, it might even make sense to store a simplified representation that’s easier to use/map instead.
I’ll try and have a look at this this afternoon, it’s innovation week at work so I’m willing to expand that definition slightly and have a poke around with that … not sure how far I’ll get but it’ll be worth understanding the history plugin a bit more as I always seem to butt heads with it!
I won’t have chance to look at this properly but it looks like the general plan would be to store an appendMap on the HistoryState that is a map that describes the transactions appended by appendTransaction. Then, when checking adjacency, map the current tr back through the inverse of the appendMap and check on that?
If that’s right then it looks like mapping a StepMap through another StepMap would largely involve appending a steps ranges to another StepMap with some optimisations accounting for overlaps (although ranges aren’t part of the public API of a StepMap)? It seems like it would be easier if it kept the whole mapping in state but this isn’t serialisable …
Does that sound about right or am I missing something?
I hadn’t planned to store the transactions themselves, just a mapping that represented them. But mapping proactively still seems like the better solution.