Using non-standard keyboard layouts in Windows 10 leads to ST3 keyboard combinations not working

[ArneBachmannDLR]

Problem description

Switching the OS keyboard layout doesn't reflect for all ST3 shortcuts. It seems that ST3 sometimes uses the physical key ID to identify key combinations (CTRL, Shift, Alt) instead of the mapped character. But sometimes the actual key received by ST (as seen when sublime.log_input(True); sublime.log_commands(True)) is some completely different key, not being present on the english or german keyboard layouts - at least that's what I remember.

It might be related to the fact how the Microsoft Keyboard Layout Creator works, but it may also be something hardcoded into ST3.

I tried to work around it using by creating a custom sublime-keymap file, but that is no solution, as it cannot detect the keyboard language/layout switch from the OS and should only apply to one specific layout.

Examples:

• ctrl+f (find) must be mapped to ctrl+t because my keyboard layout emits f where the letter f is printed on the german keyboard (OK).
• ctrl+g (goto) must be mapped to ctrl+; which is odd, as ; is where - is on the German keyboard, nowhere close to g, also not on the UK-english keyboard

Preferred solution

Keyboard shortcuts should by default work with modified keyboard layouts, unless the user assign a different key combination (e.g. to reflect their own language better in the letter).

Also keyboard mappings should allow to distinguish between Windows keyboard layouts.

Related to #392 .

[BenjaminSchaaf]

Does this only happen in ST or also in other apps? Can you provide a way to reproduce this?

[deathaxe]

ST only.

On a german keyboard layout the bindings...

{ "keys": ["ctrl+/"], "command": "toggle_comment", "args": { "block": false } },
{ "keys": ["ctrl+shift+/"], "command": "toggle_comment", "args": { "block": true } },

... actually map to # key and ...

{ "keys": ["ctrl+`"], "command": "show_panel", "args": {"panel": "console", "toggle": true} },

... maps to ctrl+ö.

It's like no matter which keyboard layout you have, you need to know where the english keys are located to be able to create correct mappings.

It's doable on a german layout as main keys don't differ much from english, but I can imagine it to be a pain in other countries.

Windows 10, ST 4094

[BenjaminSchaaf]

Keyboards on Windows have a separate mapping from hardware keys to shortcuts and from hardware keys to actual characters. On the german keyboard the hardware key \ is mapped to the # character, but the / shortcut. You can see this effect in other applications like VSCode and Edge, where pressing ctrl+# is handled as a ctrl+/ shortcut.

You can see keys being properly mapped with layout like US DVORAK (where all the characters and shortcuts change location together), and Russian (where all the characters change, but shortcuts are maintained). This is simply how shortcuts work on windows.

@ArneBachmannDLR German QWERTZ has the same location for f and g on the keyboard, are you using a different keyboard layout?

[ArneBachmannDLR]

OK, so this happened in ST, but I cannot guarantee it didn't happen in other apps as well, as I was never sure which keyboard layout was currently being active, so a lot of mistakes and false assumptions happened. I think Firefox hat similar problems with hotkeys of changed keys.

And yes, this was after designing my own keyboard layout with MSKLC, which is 50% different from German or UK keyboards.

I noticed however, that the installed layout was named something like "UK english - my layout", so it seems it was originally derived form the Uk keyboard and might have the physical key mapping stored somewhere (I'm just guessing). I might need to create it from scratch to make an independent test.

[BenjaminSchaaf]

ok, in that case considering we're working as expected with all the built-in keyboard layouts and firefox had the same issues I'm going to close this as it's clearly an issue with the custom layout.

[ArneBachmannDLR]

I don't understand. If I press Ctrl+Shift+P then it should open the suggestions box, no matter what key creates the "P" character in my layout. What can I do to make ST recognize the correct shortcut without mapping all keys manually to shortcuts? That can't be right and wouldn't work when switching between layouts anyway.

[BenjaminSchaaf]

If I press Ctrl+Shift+P then it should open the suggestions box, no matter what key creates the "P" character in my layout.

Take for instance the russian cryllic keyboard layout: There is no "p" character in the layout, Ctrl+Shift+З must trigger the keybinding for ctrl+shift+p. And US Dvorak: The "p" character is in place of the "r" and thus Ctrl+Shift+r must trigger the keybinding for ctrl+shift+p. We can't deviate from the way a windows a application is supposed to work without breaking other keyboard layouts here.

What can I do to make ST recognize the correct shortcut without mapping all keys manually to shortcuts?

The fix would be in your keyboard layout. Comparing a custom DVORAK with QUERTY shortcuts keyboard layout to a regular DVORAK layout it looks like the 2nd column dictates which keys are used for shortcuts. You can see as expected in the first one that 13 is mapped to the R key, but the p character.