Skip to content

engine: force-by-selection follows the text, not the current layout - #68

Merged
vstrelnikof merged 1 commit into
Just-Code-NET:mainfrom
iga566-gh:pr/selection-direction
Sep 8, 2026
Merged

vstrelnikof merged 1 commit into
Just-Code-NET:mainfrom
iga566-gh:pr/selection-direction

Conversation

@iga566-gh

Copy link
Copy Markdown
Contributor

Selection conversion picked its source layout from layout_switcher.current(). That is the wrong question once the layout has moved on since the text was typed — which is exactly what the next word does on auto-correction. The guess then named the layout the caret is in now, transliterate_to's own guard refused it (the text carries no letter of that layout), and the force-switch did nothing, silently.

converted() now tries both directions, current layout first and the neighbour second. Nothing is forced through blind: transliterate_to already refuses a source the text has no letter of, so the wrong direction rejects itself and the right one is what remains. The three regression tests build a bare engine and drive converted() directly, which is why it becomes pub(in crate::engine) — the tests sit one module up from switcher.

Measured. macOS 26 (M1 Pro) and Windows Server 2025, both on a 0.34.0 build carrying this change: a phrase selected and converted, then converted back with the other layout now active, and again — each press converts from the first press, whichever layout is current at the time (selection converted from=en-US to=ru-RU, then from=ru-RU to=en-US, and so on). On Windows the same scenario on stock 0.34.0 could not be measured for this bug alone: the manual-switch path there stalls on a separate hook issue, which is the next PR, stacked on this one.

Platform-neutral, poltertype-core only. cargo xtask style clean; cargo test -p poltertype-core 407 passed (400 + the three here + the #65 tests upstream); clippy -D warnings clean on the host and for x86_64-pc-windows-gnu.

converted() trusted layout_switcher.current() for the source layout.
If the layout moved on since the word was typed — exactly what the
next word does on auto-correction — the guess was wrong,
transliterate_to's own guard refused it (no letter of that layout in
the text), and the force-switch silently did nothing.

Both directions are tried now, current first, falling back to the
swap when the text does not belong to it. transliterate_to already
refuses a source layout the text carries no letter of, so the wrong
direction rejects itself and nothing is forced through blind.

Measured on macOS 26 and Windows Server 2025 with the fix: repeated
presses on one selection convert it back and forth, each from the
first press, whichever layout is active at the time.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

@vstrelnikof vstrelnikof left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the code and tests locally. The fix correctly identifies the source layout from the text content rather than trusting current(), which can be stale after an auto-correction moved the layout on. The fallback via or_else is clean — transliterate_to's own guard rejects the wrong direction, so nothing is forced through blind.

Three regression tests cover the bug (wrong current()), the normal path (right current()), and the edge case (text belonging to neither layout). All 407 core tests pass, clippy clean.

@vstrelnikof
vstrelnikof merged commit e8a9c6e into Just-Code-NET:main Sep 8, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants