macOS dead key support

[hjanuschka]

hello 🤚

again, nice programm! really love it.
with one of the recent commits, havent figured out yet which one.

my terminal is unable (or atleast not reliable) able to produce a ~ with a german-qwertz keyboard.
(this used to work a couple of weeks ago, when last pulled the master)

kitty.conf

font_family Knack Nerd Font
font_size 16
term xterm-256color
macos_option_as_alt no
macos_titlebar_color "background"
map super+v paste_from_clipboard
map super+c copy_to_clipboard

sample: https://www.youtube.com/watch?v=goJyeonLERQ&feature=youtu.be

i was typing "ALT+N" - the first time it produces a : and later repetitions produce the correct ~ however once ~ appear CTRL+A does not go to beginning of line, but produces a ^A

can you help me with this? - right now this is a blocker and forced me to switch back to another terminal.

as for the : actually renders my vim unusable.

edit: using OSX self-compiled from current master

[kovidgoyal]

Use git bisect to see which commit is causing it. You can narrow down the likely culprits by looking at the history of glfw/cocoa_window.m Most likely it is b59d7dd

[kovidgoyal]

Looking at the code, this is likely because option+n is a dead key (i.e. you press it and then press another key to generate some text). For example on the US keyboard you press option+e and then a letter to generate the letter with an accent. This is not actually supported in glfw (the windowing toolkit kitty uses, see glfw/glfw#41 it's on my TODO list to see if I can hack in support for dead keys on macOS into glfw (like I did for linux), the problem is Apple's text handling API is not very flexible, so trying to map it onto glfw is not easy.

[hjanuschka]

according to my bisect it is this commit 582500d that introduced the change, before, this one e.g: e119ed0 (been using this for ages) works.

i have to press ALT+N+SPACE(or some character) to produce the ALT+N tilde ~ - which is pretty much the same behaviour as on other text input on osx.

the current master - infact makes it impossible for me to use kitty, since i am not able to do a ~ inside vim - where the first char is a : triggering vims command prompt :/

any ideas? - let me know if you'd need some more debug info from me.

bisecting from: e119ed0 to
3d99361

[kovidgoyal]

Like I said, you have to wait for me to get around to implementing dead key support in glfw (sadly the maintainers of glfw dont seem to want to fix this anytime soon themselves). I'm surprised to hear that it ever worked in kitty, since glfw has never supported dead keys. If it did work it was accidental (two bugs in glfw canceling each other out).

In the meantime you can simply use the send_text feature in kitty.conf to map some keypress to send ~. Note that you wont be able to use a dead key combination such as alt+n instead use something like cmd+n or similar.

[hjanuschka]

ok so right now, i am going to revert my local version to the e119ed0 which seems to work, as i need a productive env.
and i try to digg into glfw - with no promise et-all - i really love kitty, the concept is super awesome, the lightwight, and the performance are super great!

[kovidgoyal]

I have implemented dead key support in GLFW. Tested with US and Unicode hex input keyboard layouts. For example, with US layout and macos_option_as_alt=no pressing option+e and then i results in an accented i.

[hjanuschka]

❤️ ❤️ ❤️ ❤️
i can confirm that the current HEAD on master works without a flaw!! many thx for your hard work on the whole project.

[pedro-carneiro]

I'm using a portuguese keyboard in macos, and I'm unable to print a ~ (tilde) key.

For example, when pressing ~/, I would expect to see ~/ in kitty, however it only displays /.

The key works well in other examples, like pressing ~a yields ã, as expected.

When using kitty with the --debug-keyboard option, the following output is shown:

2019-01-21 16:10:00.371 kitty[6088:75364] scancode: 0x27 (~) mods: none char_count: 0 deadKeyState: 2 
2019-01-21 16:10:00.373 kitty[6088:75364] Ignoring dead key.

I can reproduce this with or without a config.

I'm unsure if this is an issue or not. Apologies for digging up an old thread, and thanks for your work in advance 🙏 ❤️

[Luflosi]

Try macos_option_as_alt no in your kitty.conf, it might fix your issue.

[pedro-carneiro]

I already have that option in my kitty.conf, but the issue persists.

[kovidgoyal]

That is the same issue as mentioned in #1311, basically when a multi-key
compose sequence is aborted, the unused keys are dropped instead of
being sent. This may or may not be fixable, but it will have to be
looked at in GLFW.

[pedro-carneiro]

FYI, the issue I described above is fixed in version 0.14.0 🎉 🙏