With the various ways that tokenizations can transition depending upon which potential inputs are applied, it's possible for multiple different tokenizations to transition into the same one. As such, there will no longer be "just one" way that a tokenization is reached.
Accordingly, it's best to perform word-boundary realignment operations (splits, merges) separately from text-editing operations (inserts, deletes).
Build-bot: skip build:web
Test-bot: skip
As the next work in line will introduce new, specialized spur types designed to replace the current 'legacy spurs', it is wise to clarify existing search-graph unit tests and which sections of the code they actually target. We'll eventually drop behaviors specific to 'legacy' spurs, but those that apply to the new incoming specialized spur types should be preserved.
At the same time, it may be wise to improve the unit testing of each specific type by placing each within its own specialized unit-test suite, then adding new tests that test and clarify the role of each type.
Build-bot: skip build:web
Test-bot: skip
The removed bits of code were already refactored into LegacyQuotientSpur's implementation. They just... weren't removed from their original source.
There's a chance that the original removal got undone during a rebase, but either way, it's best to do this cleanup now, as this code would impact some of the specialized spur code coming up.
Build-bot: skip build:web
Test-bot: skip
The command shortcuts that were used by Web
scripts to create bundles via `esbuild` were not
properly handling the $KEYMAN_ROOT path when it
contained a space. These changes will rectify
this behavior and permit builds for such cases.
Build-bot: skip build:web
Test-bot: skip
When SearchQuotientCluster nodes are split, there is no guarantee that the split will be perfectly clean for all paths leading into the cluster. Even if so, there's also no guarantee that it will be placed the same way for all such paths.
Suppose the following cases:
- a, bc, d, e
- a, b, c, de
Splitting at index 3 may result in a clean split both ways, but the first sequence splits after the second input, while the second sequence splits after the third. These cannot be clustered together due to representing different (diverging) intervals of the user's keystroke-input sequence.
Splitting at index 4 has its own version of this problem: the first sequence splits cleanly after 3 inputs, while the second splits in the middle of the 4th input. Again, the represented input intervals diverge, requiring different representations for the split results.
Build-bot: skip build:web
Test-bot: skip
This PR serves to implement SearchQuotientCluster.merge() in full. If two halves of a previous .split() operation are passed in, they should be fully remerged - into a single, refused SearchQuotientNode segment.
Build-bot: skip build:web
Test-bot: skip
This is to prepare for corrections from alternate tokenizations that could result from fat-fingering whitespace keys or similar effects.
Build-bot: skip build:web
Test-bot: skip
To make this cleaner than it may otherwise be, I've added a new web/ "imports" entry that provides a simple way to reference the test-utility file. It'd likely be worth the time and effort to cherry-pick this bit to `master` and leverage it to simplify import patterns for the other test-utility definitions.
Build-bot: skip build
Test-bot: skip
