mirror of
https://github.com/wez/wezterm.git
synced 2024-11-23 23:21:08 +03:00
fe48951e7a
One of the default key assignments was registered as `SUPER+SHIFT+{` which worked on macOS, but on Linux, would never match because the keypress over there was (correctly) reporting as `SUPER+{`. I originally thought that the user reported issue was a linux normalization problem, but in looking deeper, the issue is really that macos is doing something funky! On macos we collect the interpreted key event as a string, and also the interpretation of that event without any modifiers applied. For letters this means that eg: `ALT-l` reports as `¬` for the processed string and `l` for the unmodified string. That's good! However, for punctuation we get a backwards result: SUPER+SHIFT+[ produces `[` for the processed text and `{` for the unmodified text! This commit tries to detect this, using a heuristic that is potentially bad on non-US layouts: if both the processed and unmodified strings are punctuation then we bias to the unmodified version. With that change, that key press is correctly reported as `SUPER+{`, and we can fix the key assignment registration to reflect that. I quickly checked the behavior of pressing that same physical key combination with a DEU layout active, and it appears that the unmodified stuff is also flipped there; we get a lower-case version of something that I think should be uppercase. This commit doesn't change that behavior: ``` key_event KeyEvent { key: Char('ü'), modifiers: NONE, raw_key: Some(Char('Ü')), raw_modifiers: SHIFT | SUPER, raw_code: Some(33), repeat_count: 1, key_is_down: true } ``` refs: https://github.com/wez/wezterm/issues/601 |
||
---|---|---|
.. | ||
examples | ||
src | ||
build.rs | ||
Cargo.toml |