Alt-combinations with Kitty on macOS not working (enhanced keyboard protocol question)

[mdomke]

I have the problem that I cannot use the Alt related key combinations like Alt-., Alt-;, etc. on macOS using the Kitty terminal emulator (0.28.1). I was reading through the issues

• alt-related key-combination seems not working in macOS. #2469
• Some alt commands do not work on kitty terminal #4240

where the accepted solution seems to be to use the macos_option_as_alt = yes setting for Kitty. The problem with that is, that I cannot access the alternate symbols on my keyboard anymore. Let's say I was using the "US International" layout, pressing Alt-o should give me the character "ø", but instead I get

λ showkey -a 
<ESC>o

In my head, the enhanced keyboard protocol is supposed to help the editor understand which key combination has been pressed and not only provide the resulting text, but maybe I'm wrong.

If I was pressing Alt-. Kitty should actually report the following information to Helix if the macos_option_as_alt is set to no

Alt+LEFT_ALT PRESS
CSI 57443 ; 3 u

Alt+. PRESS ≥
CSI 46 ; 3 ; 8805 u

Alt+. RELEASE
CSI 46 ; 3 : 3 u

LEFT_ALT RELEASE
CSI 57443 ; 1 : 3 u

so that in normal-mode this could be interpreted as repeat_last_motion and in insert-mode this could be the Unicode character "≥".

tl:dr

How can I use the alternate keys on my Keyboard and still use the Alt key-combinations with Kitty on macOS?

Version info

λ hx --version 
helix 23.05 (7f5940be)

λ kitty --version
kitty 0.28.1 created by Kovid Goyal

[the-mikedavis]

The enhanced keyboard protocol allows us to distinguish between terminal codes that are otherwise ambiguous (for example ret has the same escape sequence as C-m, tab as C-i and esc as C-[) and listen for codes that aren't otherwise sent by a host terminal (for example press/release events or the super/meta key). Option's unicode input ability is a native MacOS thing and setting the macos_option_as_alt config option tells MacOS to not interpret Option keybinds as unicode input. AFAIK there isn't any interaction between them: we don't get the unicode input text when that option is set to yes, just the keycodes.

[mdomke]

I think I'm misunderstanding how the process of handling key events works exactly. When there is no special treatment from the terminal emulator (e.g. macos_option_as_alt=no) macOS will do its Alt-keycombo-thing to insert "special" Unicode characters. This works just fine with Helix and everywhere else! This means that in insert-mode I can access the full range of characters on my keyboard.
The main problem I see is that applications that want to use an Alt-keycombo themselves have trouble finding out if the user wanted to press Alt-. when they actually just get ≥. In my understanding, the enhanced keyboard protocol could help here, because it gives you the information about which keys exactly have been pressed. My assumption was therefore that regardless of the macos_option_as_alt-setting Helix could interpret either

CSI 46 ; 3 u

or

CSI 46 ; 3 ; 8805 u

as Alt-. when in normal-mode since CSI 46 ; 3 means just that. I cannot tell if all of this makes sense in the scope of how the editor handles key press events, but in my understanding, there could be a way for Helix to use the Alt-keymappings and allow the macOS users to insert non-ASCII characters.

[the-mikedavis]

We don't currently receive CSI 46 ; 3 ; 8805 u. The enhanced keyboard protocol is enabled progressively so we only get the parts of the sequences that we ask for. Currently we only ask for two parts:

helix/helix-tui/src/backend/crossterm.rs

Lines 130 to 138 in e0bb032

	if self.supports_keyboard_enhancement_protocol() {
	execute!(
	self.buffer,
	PushKeyboardEnhancementFlags(
	KeyboardEnhancementFlags::DISAMBIGUATE_ESCAPE_CODES
	| KeyboardEnhancementFlags::REPORT_ALTERNATE_KEYS
	)
	)?;
	}

kitty +kitten show_key -m kitty enables all parts of the protocol. With what we enable now and with macos_option_as_alt=no, we receive ≥ (no CSI, just a UTF8 byte sequence) so we don't see any modifiers being pressed or .. With macos_option_as_alt=yes we only get A-. and no mention of ≥.

It should be possible to interpret A-. as both A-. for the sake of keybindings and ≥ in insert mode though. We would just need the "report associated text" and probably the "report all keys as escape codes" parts of the protocol implemented upstream and enabled within Helix.

[mdomke]

What do you mean with "implemented upstream"? Is this a missing feature in crossterm? It is kinda unfortunate that I can only either type umlauts with my keyboard or use the many Alt-based key combos in Helix, but not both. I would also try to contribute, but I might need some pointers where to start.

[the-mikedavis]

Yep, the "report associated text" part isn't implemented yet in crossterm. See https://github.com/crossterm-rs/crossterm/blob/1efdce7ef63cba6992729db5f22262a60936fa8b/src/event.rs#L266-L269: in the initial PR that added support for the protocol, that part was left for future work. See crossterm-rs/crossterm#754 as an example for expanding support.

[pr0g]

I ran into a similar issue to the original question (I wanted Alt-C to work on macOS to extend the cursor up - copy_selection_on_prev_line using Helix in Kitty).

I was able to get it working by adding the following to my kitty.conf:

macos_option_as_alt left
map opt+c send_text all \x1bc

I hope this helps someone else, it seems to be working well for me now.