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
hjanuschka
All 12 comments
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
on 18 Apr 2018
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 https://github.com/glfw/glfw/issues/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.
kovidgoyal
on 18 Apr 2018
according to my bisect it is this commit 582500d3e9f438f548f6c90a1d0b0a418299dc2d that introduced the change, before, this one e.g: e119ed0daa16083886de0a60eeee37f27b4cded5 (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: e119ed0daa16083886de0a60eeee37f27b4cded5 to
3d993617906c6130fb116cf733cbcdac6f51a777
hjanuschka
on 18 Apr 2018
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.
kovidgoyal
on 19 Apr 2018
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!
hjanuschka
on 19 Apr 2018
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.
kovidgoyal
on 20 Apr 2018
鉂わ笍 鉂わ笍 鉂わ笍 鉂わ笍
i can confirm that the current HEAD on master works without a flaw!! many thx for your hard work on the whole project.
hjanuschka
on 20 Apr 2018
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 馃檹 鉂わ笍
pedro-carneiro
on 23 Jan 2019
Try macos_option_as_alt no in your kitty.conf, it might fix your issue.
Luflosi
on 23 Jan 2019
I already have that option in my kitty.conf, but the issue persists.
pedro-carneiro
on 23 Jan 2019
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.
kovidgoyal
on 23 Jan 2019
FYI, the issue I described above is fixed in version 0.14.0 馃帀 馃檹
pedro-carneiro
on 24 May 2019
Related issues
jasminabasurita
路
3Comments
Nudin
路
3Comments
hdriqi
路
3Comments
JJGO
路
3Comments
hujianxin
路
3Comments
Most helpful comment
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.