UnicodeMath: A way to store "TokenExtraInfo". Probably a separate vec![TokenExtraInfo]. Whenever the input gets modified, we update the token extra info.
There were store
- connected tokens for starting bracket
- is_valid for closing brackets, true if the last parse found a good opening bracket, false otherwise
And then we can easily handle everything. Like when we insert a new bracket in the middle of existing round brackets: [((((a])))) and (((([b))))] are cases where we can pick the "whatever the previous parse said" error recovery.
Hmm, how about "valid = aggressively do error recovery if we don't find what we expect (e.g. closing bracket" else "paranoid guesswork mode".
So like if ( is valid, then we can continue walking for as long as we want, even if we encounter say }]}]
Meanwhile if ( is invalid, then we revert back to the usual "unknown token = abort asap" behavoir.
Empty errors get "inserted" into the token whenever a deletion happens. Well, not exactly inserted, more like the existing one gets replaced.
Empty tokens are "invalid" (have that flag)
If an empty token becomes valid, then it's removed.
After calling "TextBox.delete()" we immediately call "TextBox.cleanup()" to get rid of such valid empty tokens, and maybe also to get rid of repeated empty tokens.
But I don't think I need empty errors. For example, if I have
1+"quoted text"+5
And then delete a quote
1+"quoted text+5, then I go "hmm, an invalid starting quote. I'll now only put invalid tokens in the string, I don't want to accidentally put something valid into it".
UnicodeMath: A way to store "TokenExtraInfo". Probably a separate vec![TokenExtraInfo]. Whenever the input gets modified, we update the token extra info.
There were store
And then we can easily handle everything. Like when we insert a new bracket in the middle of existing round brackets: [((((a])))) and (((([b))))] are cases where we can pick the "whatever the previous parse said" error recovery.
Hmm, how about "valid = aggressively do error recovery if we don't find what we expect (e.g. closing bracket" else "paranoid guesswork mode".
So like if ( is valid, then we can continue walking for as long as we want, even if we encounter say }]}]
Meanwhile if ( is invalid, then we revert back to the usual "unknown token = abort asap" behavoir.
Empty errors get "inserted" into the token whenever a deletion happens. Well, not exactly inserted, more like the existing one gets replaced.
Empty tokens are "invalid" (have that flag)
If an empty token becomes valid, then it's removed.
After calling "TextBox.delete()" we immediately call "TextBox.cleanup()" to get rid of such valid empty tokens, and maybe also to get rid of repeated empty tokens.
But I don't think I need empty errors. For example, if I have
1+"quoted text"+5
And then delete a quote
1+"quoted text+5, then I go "hmm, an invalid starting quote. I'll now only put invalid tokens in the string, I don't want to accidentally put something valid into it".