CTRL modifiers don't work on non-latin layouts #2845
Comments
|
Dear @wez, is there anything I could add here to clarify the problematic code? I've tried to dig into the code, but I have zero experience with rust, unfortunately |
|
Dear @wez, happy New Year! Have you had a chance to take a look at the issue? |
|
Hi! Sorry, I haven't been able to get to this yet. The behavior you're describing sounds similar to AltGr processing on Windows, but with the Ctrl key instead of the Alt key in the RU layout. Perhaps there is a need for something like |
|
I've tried the config, it behaves the same way: |
github-actions
bot
removed
the
waiting-on-op
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@gagbo this specific issue is tracking something that applies only to X11/Wayland. I think you're experiencing this macOS issue: |
|
My experience with the Greek layout keyboard in KDE is that WezTerm's shortcuts with Ctrl + Shift + Alt modifiers are working if the left-side modifier keys are pressed (LeftCtrl + LeftShift + LeftAlt) and not working if the right-side modifier keys are pressed (RightCtrl + RightShift + RightAlt). This happens even with the system-level shortcut for keyboard layout change disabled (so, it could be unrelated to the issue #3010 I had opened before). |
|
Hello, another kind reminder about the issue. Just checked, it's the same behavior on version |
For eg: RU layout, CTRL-S shouldn't result in ы in the context of a terminal. The approach taken here is similar to kitty; when the key combination doesn't produce a definitive composed output, and when any of ctrl/alt/super are present, we treat the keypress as though it were the same as the one from the system default keymap. The result is that ctrl-c now works like ctrl-c and alt-b and alt-f work like their latin counterparts. Hopefully there are no downsides to this! refs: #2845 refs: kovidgoyal/kitty#606
|
@Felixoid I just pushed a commit to |
wez
added
the
fixed-in-nightly
|
Yay, it looks solved to me! |
|
@wez the commit didn't solve the case I had mentioned above about (LeftCtrl + LeftShift + LeftAlt) working but (RightCtrl + RightShift + RightAlt) not working in greek layout. This happens because in greek layout there is a distinction between Alt and AltGr, and the LeftAlt is registered as Alt while the RightAlt is registered as AltGr. So, for example, in greek layout, the shortcut for horizontal split is not working when pressing (RightCtrl + RightShift + RightAlt + %), whereas it is working when pressing (RightCtrl + RightShift + LeftAlt + %). I am not sure if your recent patch was expected to also catch this case with Alt vs AltGr or if it was only to help with the shortcuts such as (Ctrl + d) in different layouts. In any case, I confirm myself too that, with this patch, (Ctrl +d) now works with the greek layout. So, thank you for this improvement at least! |
|
@Ernest0x that sounds like a separate issue to me. On macOS we have some options that control when we route keys via the IME/composition layer: https://wezfurlong.org/wezterm/config/keyboard-concepts.html#macos-left-and-right-option-key it sounds like perhaps this same concept should be introduced to X11/Wayland. Please open a separate issue to track that! |
|
Now, after the recent commit, pressing Ctrl-Z gives the ascii character ^Y and Ctrl-Y gives ^Z. This is because in the german keyboard layout (among other differences) the keys for Y and Z are swapped. ctrl-shortcuts should work by Phisical(S) and not Char('ы') |
This is fixing a regression introduced by the fix for #2845. The resolution for this is relatively straightforward, but took a bit of effort to plumb. Previously: * CTRL/ALT/SUPER-modified keys with no explicit expansion would end up just taking the US layout version of the key. That worked well for the intended problem with non-latin layouts, but for eg: German layouts it caused expansion to totally the wrong thing Now: * CTRL/ALT/SUPER-modified keys which effectively expand to non-ascii text (eg: cyrillic "Es") now take the equivalent key press from the US layout (which would be "c" in the "Es" case). For European layouts this heuristic seems to avoid unexpected effects, but could do with some validation from native users. To support this, the xkb code splits the `Keyboard` struct out from some of the higher level logic and introduces a `KeyboardWithFallback` struct that is built out of the user-selected keyboard layout, and the fallback keyboard. Now the fallback keyboard is fed the same key inputs as the selected keyboard to correctly model the key combinations. refs: #3610 refs: #3933
|
@olaf-rogalsky see #3610 |
|
should we close the issue as solved? I think so, unless there's some hidden part |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
What Operating System(s) are you seeing this problem on?
Linux X11, Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
KDE plasma, but it's reproducible on both X11 and Wayland
WezTerm version
20221206-093635-92e851d6
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
As described in #678, the CTRL modifiers don't work in the terminal when the RU keyboard layout is active
To Reproduce
Open
wezterm, change layout to non-latin, try^cor^sConfiguration
no additional configuration
Expected Behavior
ctrl-shortcuts should work by
Phisical(S)and notChar('ы')Logs
Anything else?
No response
The text was updated successfully, but these errors were encountered: