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
As with the prior PR, this moves correction-search path merging onto SourceQuotientSpur, rather than expecting ContextToken to manage it when multiple paths to construct a token exists.
Build-bot: skip build:web
Test-bot: skip
Once we support modeling of multiple quotient-graph paths to construct individual context tokens, it's notably less straightforward to split or merge the correction-search paths on the token level. It's instead wisest to implement this via the SearchQuotientNode interface and its implementing types, which are designed to recursively model all relevant paths and thus can facilitate these operations more directly.
Build-bot: skip build:web
Test-bot: skip
