engine: force-by-selection follows the text, not the current layout - #68
Merged
Merged
Conversation
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
approved these changes
Sep 8, 2026
vstrelnikof
left a comment
Member
There was a problem hiding this comment.
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_toalready 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 driveconverted()directly, which is why it becomespub(in crate::engine)— the tests sit one module up fromswitcher.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, thenfrom=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-coreonly.cargo xtask styleclean;cargo test -p poltertype-core407 passed (400 + the three here + the #65 tests upstream); clippy-D warningsclean on the host and forx86_64-pc-windows-gnu.