At the moment, when a match touches e.g. noted text, it's discarded when we try to add it to the document.
But we still check against noted text on the server. This can cause problems. E.g. for a rule that checks to see if the start of a sentence is capped up, where square brackets denote a noted range:
... end of an example sentence[.] or is it?
Typerighter will see
... end of an example sentence. or is it?
and we'll get a match suggesting or -> Or – but we want Typerighter to see
... end of an example sentence or is it?
What's changed?
This PR adds an skipRanges param to the check interface, allowing us to skip e.g. noted ranges on the server.
To do this, we remove the skipped ranges from the blocks being checked on the way in (before they're presented to matchers), but map across the matched ranges on the way out to ensure that character positions are still correct.
For example, given the phrase
Example [noted ]text
| | | |
0 8 15 19
and a match for text:
matcherPool removes the skipped ranges from the block, so the snippet [noted ] is removed for the range (8, 15)
the matcher sees Example text where text covers the range (8, 12)
the matcher produces a match covering range (8, 12)
the final match is mapped back through the skipped range in matcherPool to the correct position, (16, 19)
How to test
The automated tests should be thorough and pass as expected.
Follow the instructions in the accompanying prosemirror-typerighter PR for an easy way to test manually.
Definition of Success
Skipped ranges aren't seen by checkers, and their presence doesn't disturb the position of matches in the document.
Dev notes
There was some discussion as to whether this logic belonged on the client or the server.
Keep it on server
Place of most control re: deployment
Guarantee a single implementation, rather than many
Ensures that any client has access to this logic (rather than rolling n implementations for n clients, or clients sharing code)
Move it to client
Colocates (to a certain extent) the generation and removal of skipped ranges – although these are also decoupled, as the first op belongs to the plugin consumer and the second to the plugin itself
Simplifies the server interface
Any additional thoughts welcome – it'd be trivial to shift this logic client-side before or after merging in a way that would be transparent to the consumer.
Problem
At the moment, when a match touches e.g. noted text, it's discarded when we try to add it to the document.
But we still check against noted text on the server. This can cause problems. E.g. for a rule that checks to see if the start of a sentence is capped up, where square brackets denote a noted range:
... end of an example sentence[.] or is it?Typerighter will see
... end of an example sentence. or is it?and we'll get a match suggesting
or -> Or– but we want Typerighter to see... end of an example sentence or is it?What's changed?
This PR adds an
skipRangesparam to the check interface, allowing us to skip e.g. noted ranges on the server.To do this, we remove the skipped ranges from the blocks being checked on the way in (before they're presented to matchers), but map across the matched ranges on the way out to ensure that character positions are still correct.
For example, given the phrase
and a match for
text:matcherPoolremoves the skipped ranges from the block, so the snippet[noted ]is removed for the range(8, 15)Example textwheretextcovers the range(8, 12)(8, 12)matcherPoolto the correct position,(16, 19)How to test
The automated tests should be thorough and pass as expected.
Follow the instructions in the accompanying prosemirror-typerighter PR for an easy way to test manually.
Definition of Success
Skipped ranges aren't seen by checkers, and their presence doesn't disturb the position of matches in the document.
Dev notes
There was some discussion as to whether this logic belonged on the client or the server.
Keep it on server
Move it to client
Any additional thoughts welcome – it'd be trivial to shift this logic client-side before or after merging in a way that would be transparent to the consumer.