Incorrect text after layout correction occurs

[AlexBokhankovich]

PolterType version

0.18.0

OS and desktop environment

Cachyos wayland KDE plasma

How did you install it?

AppImage (Linux)

Keyboard layouts involved

en-US + ru-RU

Anything unusual in your input stack?

No response

What happened, and what did you expect?

Sometimes app incorrectly changing layout of typed words^ capital letters are incorrect and sometimes random symbols incorrectly changed.
I have no stable repro for this but I can start app with maximum logs enabled and when issue occurs attach logs here. I just need information how to enable maximum logs and what other info could help to solve te issue/

Log excerpt

Relevant config.toml excerpt (optional)

[vstrelnikof]

Thanks — that was enough to find a real one, and it is fixed on main.

PolterType was treating Caps Lock as a second Shift. When it retypes a word it re-presses the Shift states it recorded, and the lock is still on while it does, so xkb applies it twice: ALPHABETIC keys route Shift and Lock to level 2 separately and leave the combination on level 1, so a capital the lock produced comes back lower-case — and digits and punctuation do not list Lock at all, so a 1 typed under the lock comes back as !. That is both halves of what you described.

Worse, on Linux it counted presses of the Caps Lock key instead of reading the lock. Give that key another job — caps:escape, caps:ctrl_modifier, or "Caps Lock switches layout" — and it latches nothing at all, while every press still flipped an internal flag that then stayed wrong for the rest of the session. The lock is now read from the keyboard's own Caps Lock LED, so a key that locks nothing changes nothing.

One quick check would tell us whether this is your bug: when you press Caps Lock, does the Caps Lock light actually come on? If your layout switching is bound to that key, it will not — and that is exactly the case that was broken. Your [engine] section from config.toml would help too: with suppress_for_all_caps and suppress_in_identifiers at their defaults this mostly shows up as PolterType going quiet, and with either of them off it shows up as the mangled text you are seeing.

For a detailed log, set log_level = "debug" under [general] in config.toml (Tray → "Edit config.toml…") and restart. That key had been written into every config file and read by nothing until this same fix, so on 0.18.1 you need RUST_LOG=poltertype=debug in the environment instead. Logs are at Tray → "Open Logs Folder…"; typed words are redacted to <6 chars>, so they are safe to attach. The line to look for is applying correction, which now carries caps=true/false.

Worth moving to 0.18.1 first in any case — it fixed a different "random symbols" case, where a word whose other-layout twin contains a bracket got corrected into it.

[vstrelnikof]

Two things for this, one shipped and one new.

The Caps Lock half went out in 0.19.0 — both the capitals coming back wrong and PolterType counting presses of the Caps Lock key instead of reading the lock from the keyboard.

0.20.0 adds a second, older cause that fits "sometimes random symbols" better than the first one did, and that nobody had a repro for because it depends on timing rather than input. A correction backspaces from the caret, and the word the force-switch hotkey acted on was the last finished one — so pressing that hotkey a moment late, after you had already started typing the next word, sent the previous word's backspace count several characters to its right and took the line apart. It has been there since the hotkey existed. It now acts on the word the caret is actually in, and where the caret cannot be accounted for it does nothing instead of guessing.

Could you update to 0.20.0 and say whether it still happens? Two things that make a follow-up easy now: log_level = "debug" under [general] actually works (it was written into every config file and read by nothing until the 0.19.0 fix), and the line to look for is applying correction, which carries caps=true/false. If it does still happen, your [engine] section would help.

[unv-unv]

I also noticed this issue on 0.21.0. Once when I typed "auto-switch " (auto-switch was on) it transformed into "ФГЕЩ-ЫЦШЕСР " (and I didn't press Caps Lock). I tried to reproduce the problem by typing "auto-switch " once more but it didn't reproduce. So it may be some floating problem.