Two-thumb: gesture stroke isn't cleared on backspace — re-typing a mis-recognized word accumulates geometry (words grow each retry)

[SHAWNERZZ]

Summary

Under two-thumb spacing (manual-spacing / combining grace), a tapped short word never auto-commits — it stays the open composing word — so the next swipe merges into it as multi-part composition, producing garbage. E.g. tap do, then swipe the next word → do's tap-points fuse with the swipe and recognize as long nonsense (disownment, disparagements, disestablishmentarian).

Repro

1. Two-thumb spacing mode on (manual spacing or combining grace).
2. Tap a short word, e.g. do.
3. Swipe the next word without an explicit space first.
4. The swipe merges into do → garbage instead of two separate words.

Root cause (traced from debug log)

In InputLogic.onStartBatchInput, a new gesture extends the open composing word whenever:

extendComposingWord = (mGestureManualSpacing || wasInCombiningMode) && cursorAtEndOfComposingWord

A tapped word like do is still the open composing word (it never auto-committed), so cursorAtEndOfComposingWord is true and the swipe extends it via the merged-trail (extend-base) path. Log shows composingBefore=do extendBase=true usedMergedTrail=true repeatedly across different garbage outputs.

This is multi-part composition working as designed (same mechanism as tap te + swipe chnology → technology) — there's just no notion of "this open word looks finished, commit it instead of merging."

Confirmed NOT the extend-base leak (PR AsafMah#61) and NOT the casing fix (#6): every merge in the log had a real composing word; no fresh word inherited a stale base.

Options

• A — commit-before-extend heuristic (scoped): before extending, if the open word is a complete dictionary word and the new input is a fresh swipe, commit it first instead of merging. Uses the complete signal from the spacing-policy design.
• B — only extend fragments, not finished tap-words: don't merge a tap-built word into a following swipe unless explicitly joined (JOIN_NEXT).
• C — spacing policy (long-term home): ties into the B6a/B6b signal-driven commit work.

Starting with option A.

[SHAWNERZZ]

Re-diagnosed (the original framing here was wrong). This is NOT about committing a tapped word before a swipe — tapping do then swiping the rest to build doesn't is the intended multi-part flow, and space stays the word-submission point. The real bug is stroke geometry not clearing on backspace:

Root cause (traced end-to-end):

• The merged stroke lives in WordComposer.mInputPointers. It's intentionally NOT cleared by reset() / backspace (so a gesture commit can re-feed it via setBatchInputWord), and ResizableIntArray.addAt(index) overwrites in place without shrinking the length.
• So when a multi-part word mis-recognizes and you backspace, the raw buffer keeps its length. Re-typing do overwrites only indices 0–1; the stale tail survives. The next swipe snapshots the whole stale buffer as the merged-trail extend base → an ever-longer garbage word, growing with each retry.
• PR fix(two-thumb): clear stale merged-trail extend-base on delete + gesture lifecycle AsafMah/LeanType#61 cleared the extend-base flag and mLiveStroke, but not the mInputPointers buffer the base is re-armed from — so the leak persisted through that fix.

Fix: reset mInputPointers when the first tap of a fresh word lands (newIndex == 0 in WordComposer.applyProcessedEvent). Covers every abandonment path (whole-word / batch / per-char-to-empty / cursor move), never touches the gesture-commit flow (batch mode is guarded), preserves multi-part (a tap extending a gesture has newIndex > 0), and can't disturb mid-word backspace coords for normal typing.

Unit-tested directly at the buffer level (WordComposerTest.testFreshWordResetsStaleInputPointers); full suite shows zero new failures vs baseline. Branch fix/two-thumb-stale-stroke-on-retry, pending on-device validation.