diff options
| author | Mitchell Hashimoto <m@mitchellh.com> | 2025-02-13 15:03:54 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-02-13 15:03:54 -0800 |
| commit | ee963f62968264157003d84d579b46b9df2e7806 (patch) | |
| tree | 64eafc1b9508af3c8c688ec76dcb5b65d53005e8 /test | |
| parent | 710ea1c8d9a1005a9f7f03fe98297b13a21b8e44 (diff) | |
| parent | b44b1086d355fc269dde5979bc69e85cdf1990b2 (diff) | |
macOS: fix invalid kitty keyboard encoding of control characters (#5747)v1.1.2
Fixes #5743
This fixes a terrible regression where by fixing one issue we introduced
another, and the other is that ctrl keys didn't work with programs with
Kitty keyboard protocol.
The problem is that our fix blindly assumed control was always consumed
for translation, which is obviously wrong but I didn't think there'd be
downstream effects. The reality is that we need to be more accurate.
This PR makes it so that:
* If macOS provides us with UTF-8 text, we assume all mods were involved
except super
* If macOS does not provide us with UTF-8 text, we use whatever
UCKeyTranslate consumed
* We never allow UCKeyTranslate to consume control because it turns it
into the masked ASCII value and we don't want that.
The only _new_ behavior which fixes the bug is point 2 above.
Tested:
1. Dvorak Ctrl characters
2. Ergo-L Ctrl characters
3. US standard Ctrl characters
4. Japanese IME input Ctrl input to modify IME state
5. Ctrl keybindings with Kitty keyboard protocol in both Kitty and
Neovim
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions
