how to get alt to send escape?

[alok]

I'm trying to switch from iterm to kitty, except that the alt key in kitty does not work for me inside (neo)vim because it does not seem to send ESC, so mappings like a-s don't work.

[kovidgoyal]

Alt most definitely does send escape. Try running

cat

in the terminal and typing

alt+s

You get

^[s

Or if you are on OS X, IIRC the OS converts Alt + key into unicode characters. A bit of googling will show you how to get OS X to stop doing that. I'm not an OS X user so I can't really help with that.

[alok]

https://stackoverflow.com/questions/11876485/how-to-disable-typing-special-characters-when-pressing-option-key-in-mac-os-x

That fixes it

[justinmk]

If there's a way to do this in kitty by default on macOS I would strongly suggest doing that.

https://stackoverflow.com/questions/11876485 involves installing software or setting a system-wide setting.

Currently option (alt) chords in kitty on macOS don't do anything useful. E.g. in bash it inserts non-printable bytes--it doesn't show the expected multibyte character.

For comparison:

• In Terminal.app, with "Use Option as meta key" disabled, alt+o inserts ø (0xF8) in bash.
• In Terminal.app, with "Use Option as meta key" enabled, alt+o sends ESC + o.
  • Would be nice if kitty behaved like this by default on macOS.
• In kitty on macOS, alt+o in bash enters some unfinished state, which is then combined with the next keypress. E.g. in bash, nvim <A-o>foo<Enter> edits a file named <b8>foo.

[kovidgoyal]

I dont know of any API on macOS that allows applications to prevent the OS from converting alt+keypress into unicode input. So the only way to do it would be to bypass the key handling of GLFW and process the raw scancodes, which is probably what terminal.app does. And then you have to worry about handling people using non-standard keyboard layouts. That's way more work than I care to put in for a platform I dont use. Patches are welcome.

[justinmk]

Maybe @gnachman knows :)

[justinmk]

@kovidgoyal alacritty issue tracker has some hints, NSEvent.charactersIgnoringModifiers() seems to be the way to get "o" from alt+o. Then that could be combined with the detected ALT modifier.

alacritty/alacritty#62 (comment)

https://github.com/gnachman/iTerm2/blob/c67051d19907e77be670fa04d22d8d5710a0fc62/sources/PTYSession.m#L5817

[kovidgoyal]

Thanks, that is essentially the solution I was talking about, bypassing GLFW. That is still a pretty large amount of work, because one has to first bypass glfw and implement key event handler, then remap the key events back to glfw key events. Still, might be worth doing someday.

[kovidgoyal]

Turns out that it is possible to at least support the "option as meta" use case without bypassing glfw. Basically you just have to manually handle the case of alt + printable keys instead of relying on glfw. f137ea7

I'd appreciate it if some mac users sould test it out more thoroughly.

[justinmk]

@kovidgoyal Wonderful! Is it much trouble to post a dmg?

[kovidgoyal]

The dmg is inside the attached zip file because github doesnt allow uploading dmg files.
kitty.zip

[justinmk]

@kovidgoyal This works much better than the keymap hack I was using (which had weird interactions with tmux). No problems so far.

(Installing random tools as suggested in https://stackoverflow.com/questions/11876485/ was not a pleasant alternative.)

[kovidgoyal]

Glad to hear it :)

[kovidgoyal]

And it finally turns out that I was completely wrong. It's actually possible to do both unicode input and option as alt without bypassing glfw. 505ae90