fix(web): correct edit-path ordering at source 🖲️

[jahorton]

Rather than correcting the context-matching edit-path after it's generated, what if we just... got it right the first time?

Finally decided to really look into the cause and remedy this... and add a unit test while I was at it.

@keymanapp-test-bot skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

[mcdurdin]

What are the implications of this? What problems was it causing?

[jahorton]

What are the implications of this? What problems was it causing?

Note the changes in context-tracker.ts.

In particular, the predictive-text "context-tracking" engine seeks to align contexts before and after changes based on preserving a central band that doesn't change, then a thin area that might be altered, and only then areas that have deletions and insertions.

The ordering of the edit path, as it was before, required extra logic to "correct" this ordering on the right-hand side, near the text insertion point. Suppose a degenerate keystroke were added that emitted the following string: a b c d. In such a case, the logic in context-tracker.ts would not have caught it - there are too many whitespaces in there. Also, suppose a future in which we offer multi-word predictions - the same would apply then.

The "correction" logic was unable to handle these cases, and I originally did extend it - and the results are more complex than what is seen here. Then I realized, after a bit of inspection... that I could fix the underlying problem at its source, and in a manner that operated more simply and concisely.

---

This was giving me a few issues during at least one stage of development for #12884.

[keyman-server]

Changes in this pull request will be available for download in Keyman version 18.0.183-alpha