Shift-number key binding and locale specifics



Apologies if this has been discussed somewhere,
I did some searching but found nothing related.

In the key binding resolver:

press ctrl-shift-a, get ctrl-shift-A
press ctrl-shift-0, get ctrl-)

Somehow, for numbers only, the shift modifier is removed and the resulting binding becomes “modified” by shift directly. The same is true for letters - but they still work on lower or uppercase.

However - numbers change meaning on different locales. For example Spanish has ) on 9, not 0.
This means that binding to ctrl-) is not an option, because the meaning of the binding changes completely when international users try to use the default bindings.

Am I misunderstanding something, or is this unintended consequence?
Is there a way to bind to ctrl-shift-0 without hardcoding the modified locale char?



If I’m understanding correctly, you’re talking about this issue:


It does seem related! (The post is pretty dense and all over the place, but definitely in the same vein at least).

Is there any more info on the ‘closed’ state? It references summer of code stuff, but no real details or commit ref to check with.


How should Atom know that you wanted to press Ctrl-Shift-0 and not Ctrl-)? Also, I can imagine that Ctrl-( and Ctrl-) might be very useful for moving backwards and forwards across parenthesized expressions, or maybe for indenting. Or that Ctrl- makes sense to insert a list item in HTML – and on a German keyboard, where is not on a number key at all, you’d press that key instead of Shift and 8.


hmm, I don’t know if I can relate to that.
Why does atom show ctrl-shift-A instead of ctrl-A and ctrl-a?
Why are numbers specifically singled out?

I expected the modifier state to be on top of the keycode,
as how they are treated everywhere, like the os and even the browser platform atom is running in.


Originally, Atom did show ctrl-A and ctrl-a, but it was found to be confusing for many folks, so it was changed. Perhaps someone just forgot to include non-alpha characters in the change.


I’d imagine it’s not only confusing but really difficult to apply across locales, and platforms.
Even across windows and mac, alt + L produces ¬ , trying to account for those types of differences is just wild.

Atom is treating them as a state (which is correct), but for some reason that state is being suppressed by numbers, at the very least.

Either way, It seems to be around here, but this is the first time spelunking the keymap source. I can dig into it at some point, but it wouldn’t help if that’s intended somehow.