input: legacy encoding never encodes text for command mods on macOS #6057
Conversation
Fixes #5929 Replaces #5984 On macOS, native applications typically never encode any text for key events that use the command key. This is because the command key is used for key equivalents and "commands" and should not be used for text input. This can be verified with apps like TextEdit but also terminals like Terminal.app officially but also iTerm2 unofficially. Anything such as `Cmd+b` or `Cmd+Shift+b` will not produce any text input. Cross-platform terminals generally don't follow this, for example Kitty performs CSI-u encoding and Alacritty and WezTerm encode the text as-is (i.e. `Cmd+b` will produce `b`). On Linux, the super key (command-equivalent) does produce text input. For example, `Super+b` will produce `b` in Gnome Console, Foot, and all the cross-platform terminals mentioned above. In the interest of matching the behavior of native macOS applications, we should not encode text for command key events on macOS. We continue to encode text for the super key on non-macOS platforms.
| // with legacy encoding. | ||
| if ((comptime builtin.os.tag == .macos) and all_mods.super) { | ||
| return ""; | ||
| } |
There was a problem hiding this comment.
I will note that it is possible that this check is too late. We may want to omit ctrl sequence and other encodings as well when the super key is pressed on macOS. But the tests only cover this and this was the least-impacting change I could do with a very specific real world bug to verify it resolves.
I'd be open to a broader change with a bit more research.
|
Just so I understand... kkp encoding will still encode the associated text field when super + "b" is pressed? I am thinking we shouldn't do that and instead report it as no produced text...what do you think? |
I can confirm it does not produce text, and the behavior matches Kitty. EDIT: more specifically, we produce super + b but no associated text. |
Fixes #5929
Replaces #5984
On macOS, native applications typically never encode any text for key events that use the command key. This is because the command key is used for key equivalents and "commands" and should not be used for text input.
This can be verified with apps like TextEdit but also terminals like Terminal.app officially but also iTerm2 unofficially. Anything such as
Cmd+borCmd+Shift+bwill not produce any text input.Cross-platform terminals generally don't follow this, for example Kitty performs CSI-u encoding and Alacritty and WezTerm encode the text as-is (i.e.
Cmd+bwill produceb).On Linux, the super key (command-equivalent) does produce text input. For example,
Super+bwill producebin Gnome Console, Foot, and all the cross-platform terminals mentioned above.In the interest of matching the behavior of native macOS applications, we should not encode text for command key events on macOS. We continue to encode text for the super key on non-macOS platforms. This matches the behaviors appropriately on each platform.