Some non-US keyboard layouts not working

[nshtg]

Regarding: atom/atom#2600
@kevinsawicki

Compare US and (for example)

German keyboard layout

I think its easy to see why src/helpers.coffee is destined to fail horribly.

One example to demonstrate: I try to Toggle comments using Ctrl-/. For that I would have to press Ctrl-Shift-7 as you can see above. It registers Ctrl-?.

I don't know how, but your script somehow catches my Ctrl-Shift-7 (which would be shift+55) and makes it an ? (191) where it should make it an &.

Edit: What is that; If I press # on my keyboard it gets resolved to 3 in the keybinding resolver, but inserted correctly into the text. Something is very very wrong here! 😱

[nshtg]

Regarding that ChromeBug you told us about; It seems like it is only relevant on keydown (show 191).

keypress returns the correct value 47 for my call! Why are you using keydown in favor of keypress?

[nathansobo]

The keypress event doesn't include modifier key information if I recall correctly.

[nshtg]

Ups, I did not mean to delete. Yes indeed keypress supplies the modifier key information but it does not get triggered unless there is a key to insert. For example Ctrl-Shift-7 will not insert anything because it does not press a key - Only Shift-7 does.

But using keydown to map characters (the existing keybindings) to the user input is not really easy or straightforward I think. This guy explains it pretty good:

http://www.javascripter.net/faq/onkeypress.htm

Unlike event.keyCode of keydown/keyup events, the character codes in keypress events reflect the actual characters the user typed (and not necessarily the keys pressed). The characters may be capital or small, Latin or locale-specific. For example, depending on the current state of the client, the F key on the keyboard may produce a capital Latin letter F, a small Latin letter f, a capital Cyrillic letter A, a small Cyrillic letter a, or any other character that might be mapped to this particular key – quite a few different characters with their own character codes. Therefore, we must use the keypress event here; should we use keydown, we would get the same key code 70 (F) for all of the above.

[nathansobo]

So do you see any way of dealing with this other than lobbying Chromium to fix the underlying issues? This stuff gets confusing quickly.

On an international layout, what are the expectations for key bindings. For example, in the Greek layout they expect unmodified keystrokes to insert Greek characters, but they expect keystrokes with modifier keys to fall back to the ASCII equivalents.

[nshtg]

@nathansobo
I spent the past days reading through everything on jQuery/javascript key handling that I could find, and no, I think except for lobbying chrome there's nothing we can do. But I don't have too high expectations, I remember another crucial bug that was open for almost 7 years and no one even remotely cared.

[nathansobo]

It's not implemented in Chromium yet, but the DOM Level 3 keyboard event spec should give us exactly what we need with the KeyboardEvent.key property. It's partially implemented in Chromium and is being tracked by this issue. It looks like some of the properties have been implemented but we're still waiting on key.

[nshtg]

I saw that, yep. Let's hope they do it in the near future, but there hasn't been activity for almost a year.
😕

[mjrk]

Ubuntu 14.04, German keyboard layout, Keybinding resolver "correctly" gave Ctrl+& when I tried to press Ctrl+Shift+7 to toggle comments. It does not work, I have to press Ctrl+# (corresponds to the US layout's '/').

Thanks to the issue it's easy to figure out which keys to use and to understand why "native!" keys work according to my keyboard layout while others don't. If this issue remains open for long (depending on Chromium), I wonder if it's possible to give feedback about the situation in the Settings window - e.g. configuring my native layout and displaying its keystroke in a column next to the current Keystrokes.