I like the simplicity of the inputrules but I was hoping that they would behave like autoformat in say word or other such apps whereby the formatting/change occurs after the input completes and the autoformat can be undone separately.
It seems like when the rule is processed via the textinput it is manipulating the model before the text was applied. So if I just use the undo/redo commands as is then undo’ing that action returns it to the state just prior to that last character being typed (e.g. **bold* instead of **bold** with the final * that triggered the inputrule processing).
I also tried using the undoInputRule command such that it would be processed before the undo command (e.g. via ctrl-z) and that sort of works. The first undo would restore the text to what it would have been if the text were inserted (**bold** in my example) but that itself interferes with the history. Because if I undo again the state created by the input rule action is redone (e.g. bold) - I assume because the undoInputRule acts like a new action added to the undo stack. If I then undo again it goes to say **bold (because presumably that is the entry in the history from before the textinput rule was processed).
I think the ideal scenario would be that the input rule wasn’t processed until the transaction that involves that textinput were complete but I don’t see an easy way to do that. I mean I could try to infer it in the dispatchTransaction method but even if I can come up with a reasonable method of detecting I should do this then I’m essentially going to replicate much of the run of the rule - not the end of the world but not ideal either. Thoughts?
Been digging through the various members like appendTransactions and update on the plugin and other such members. Was also looking at whether putting the addToHistory meta data would help for that bit about the undoInputRule affecting the stack and while I didn’t completely walk down that path I’m not sure it’s going to help. So I think I probably have to do what I was suggesting - deal with this as some post processing in the dispatchTransaction and infer when the inputrule should be evaluated. I can still use the inputRule plugin and just directly call into its textInputHandler so I don’t need to duplicate that logic as I was thinking I might. But I’m open to suggestions if there’s a cleaner way to do this.
I agree that some things become conceptually simpler if input rules would first let the input’s normal effect go through and then apply their effect. However, it makes other things more awkward—the extra transaction in the history, which is sometimes unexpected.
On the bright side, the core of the inputrules library is only a hundred-odd lines of code, and it might be worthwhile to take a stab at a separate implementation that works differently.
Yes I’ve sort of swung back that way as well. The inference is getting messy since I need to ignore undo/redo and paste actions that look the same so identifying the action from the steps is more error prone although for those couple i can use the meta data but there may be others i haven’t seen yet. So I started looking into wrapping the inputrules to avoid duplicating the existing logic since i still would need almost all it does - just that it needs to do the text insertion prior to the rule’s action and it has to know that the rule would have created a transaction. So yeah long story short I think I’ll just make my own input rule type functionality. I do appreciate how modular the library is and how that let’s me easily inject/replace the things I need done differently so kudos and thanks again for the input on the issue. Have a nice weekend.
Yes that ended up working out. It’s part of code for a project i’m working on for my company so can’t show the code but the gist is basically what I said where i duplicated much of the run method except that if a match is found it calls insertText with the text and dispatches that transaction so that the text insertion is a separate operation and also i passed along the closeHistory into the plugin so that if a transaction is returned from the rule’s handler that its operation would be separate.