Describe the bug
On LeanType 4.2.2, holding Backspace sometimes deletes text quickly, but at other times deletion becomes noticeably slow or hesitant. This concerns ordinary press-and-hold deletion, not swiping on the delete key.
This is a user-observed symptom. Its exact cause has not been established by device traces. Source inspection found a reproducible inconsistency that may contribute: acceleration applies to committed text but not to an ordinary composing word.
To reproduce / expected behavior
There is no verified minimal reproduction of the intermittent phone symptom. Suggested diagnostic scenario: with suggestions enabled in a space-separated language, type several words including a long final word, then hold Backspace continuously through that word, a space and a previous word. Compare deletion across the composing/committed transitions without releasing the key.
Expected: a consistent acceleration policy during ordinary deletion, independent of whether a word is composing or resumed for suggestions. Selection deletion, autocorrection undo and whole gesture-word rejection should retain their special semantics.
These are proposed diagnostic steps, not a claim of reliable on-device reproduction. No recording, logcat or latency measurements are available. I am not planning additional device testing at present.
Source analysis / automated evidence
Audited release commit: 7e871955015d96a6ed6891ca186208d2ef4ab052. The relevant InputLogic.kt and WordComposer.kt files remain unchanged in inspected main 976a01e9d46fdcedbae9d479cbbfd6c746932229.
DELETE_ACCELERATE_AT is 20.- The ordinary composing branch applies one deletion, while the committed branch adds another above the threshold. Suggestion resumption can switch between these branches during the same hold.
- Three tests using the existing Robolectric input harness demonstrate the unequal deletion budget on unchanged release code: long composing word, resumed committed word, and crossing out of composition. They establish a deletion-count difference, not measured UI latency.
Other unmeasured candidates include synchronous InputConnection queries, counter resets after processing gaps above 200 ms, and synchronous session-word persistence. No evidence currently points to a swipe-library issue.
Previous experiment / related reports
Draft #503 is being withdrawn in favor of this issue. The branch, tests and analysis are preserved for reference; they are not a device-validated fix or a merge request to pursue at present. The PR records the experiment's review findings and corrections.
Related #439 and #463 request broader deletion gestures/behavior. This report is specifically about inconsistent speed during ordinary continuous holding.
App / device information
- Installed version: 4.2.2; installed flavor was not recorded.
- Automated tests used Standard Full; the input logic is shared.
- Model, Android version, affected editor and exact suggestion settings were not captured. No screenshot/device-specific claim is supplied.
Analysis and experimental tests were AI-assisted. Please assess the composing/committed inconsistency and whether it could explain the reported behavior; the symptom is not claimed to be fixed.
Describe the bug
On LeanType 4.2.2, holding Backspace sometimes deletes text quickly, but at other times deletion becomes noticeably slow or hesitant. This concerns ordinary press-and-hold deletion, not swiping on the delete key.
This is a user-observed symptom. Its exact cause has not been established by device traces. Source inspection found a reproducible inconsistency that may contribute: acceleration applies to committed text but not to an ordinary composing word.
To reproduce / expected behavior
There is no verified minimal reproduction of the intermittent phone symptom. Suggested diagnostic scenario: with suggestions enabled in a space-separated language, type several words including a long final word, then hold Backspace continuously through that word, a space and a previous word. Compare deletion across the composing/committed transitions without releasing the key.
Expected: a consistent acceleration policy during ordinary deletion, independent of whether a word is composing or resumed for suggestions. Selection deletion, autocorrection undo and whole gesture-word rejection should retain their special semantics.
These are proposed diagnostic steps, not a claim of reliable on-device reproduction. No recording, logcat or latency measurements are available. I am not planning additional device testing at present.
Source analysis / automated evidence
Audited release commit:
7e871955015d96a6ed6891ca186208d2ef4ab052. The relevantInputLogic.ktandWordComposer.ktfiles remain unchanged in inspected main976a01e9d46fdcedbae9d479cbbfd6c746932229.DELETE_ACCELERATE_ATis 20.Other unmeasured candidates include synchronous InputConnection queries, counter resets after processing gaps above 200 ms, and synchronous session-word persistence. No evidence currently points to a swipe-library issue.
Previous experiment / related reports
Draft #503 is being withdrawn in favor of this issue. The branch, tests and analysis are preserved for reference; they are not a device-validated fix or a merge request to pursue at present. The PR records the experiment's review findings and corrections.
Related #439 and #463 request broader deletion gestures/behavior. This report is specifically about inconsistent speed during ordinary continuous holding.
App / device information
Analysis and experimental tests were AI-assisted. Please assess the composing/committed inconsistency and whether it could explain the reported behavior; the symptom is not claimed to be fixed.