It is difficult to deal with keybindings when using non-US standard keyboard layout

[alexdima]

Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85)

In the UI and in the keybindings.json file, VSCode represents OEM key codes using the US standard keyboard:

• VK_OEM_1 (0xBA) as ;
• VK_OEM_PLUS (0xBB) as =
• VK_OEM_COMMA (0xBC) as ,
• VK_OEM_MINUS (0xBD) as -
• VK_OEM_PERIOD (0xBE) as .
• VK_OEM_2 (0xBF) as /
• VK_OEM_3 (0xC0) as `
• VK_OEM_4 (0xDB) as [
• VK_OEM_5 (0xDC) as \
• VK_OEM_6 (0xDD) as ]
• VK_OEM_7 (0xDE) as '

---

This means when VSCode renders in the UI a keybinding as Ctrl+/, it actually means Ctrl+VK_OEM_2.

• When using a US standard layout, VK_OEM_2 is physically labeled as /? and sits next to the right hand side Shift, but
• when using a Swiss German keyboard layout, for example, VK_OEM_2 is physically labeled as §° and sits next to 1.

---

This makes life quite difficult for us who use non-US standard keyboard layouts (I'm using a Swiss German keyboard on my laptop).

---

The only way to make this experience great for non-US standard keyboards is to be able to read the current set keyboard layout from the OS and then:

• render these OEM key codes in the UI according to the configured keyboard layout.
• register multiple default keybindings per action and per keyboard layout.
• AFAIK, at this time, this is not possible in electron.

---

In the short term, I would like to ask passionate non US standard keyboard layout developers to create and publish extensions that overwrite the default VSCode keybindings with keyboard layout optimized variants. Such an extension is super easy to author, it would only consist of a package.json that contributes keybindings

---

Update 30.11.2015: Electron renders the keybindings correctly in the native menu, now it is a question if it will provide API for the JavaScript side to do so too:

Under German (Switzerland), Split Editor gets correctly rendered in the menu as Ctrl+ä:

While the JS side renders it incorrectly as Ctrl+\:

electron/electron#3631 tracks the API request to Electron

[alexdima]

As a first step towards a better experience, I have pushed a widget that can help quite a lot when defining keybindings on non US standard keyboard layouts.

The widget activates when editing the keybindings.json file and translates what is typed into the key representation that VSCode understands.

[74th]

Can you use e.keyIdentifier instead of e.keyCode?
I test Shift-2(=@) with us-keyboard and @ with jis-keyboard, both values are same "U+0040".
keyIdentifer seems well in Electron.
I think almost users using only alphabet-key-binding, so mark-key-binding will be simple like String.fromCharCode(parseInt(e.keyIdentifier.substring(2),16)).

[martinsuchan]

Note this might be related to a similar bug in full Visual Studio 2015:
https://connect.microsoft.com/VisualStudio/Feedback/Details/2002769

[alexdima]

@74th keyIdentifier is completely broken on windows & linux. I tested it today a lot (under windows) and thought I'm mis-interpreting your comment, but looks like it is a known bug in chromium.

Here is what I could find -- https://code.google.com/p/chromium/issues/detail?id=428018

[74th]

I test JIS-keyboard in Ubuntu and Windows.
keyIdentifier is breken in Ubuntu and Windows like you said.
I found that ; and : are appeared same keyCode and keyIdentifier in Ubuntu and JIS-keyboard.
There are no way to completely support JIS-keyboard in Ubuntu.
In Windows and JIS-keyboard, all keys are appeared different keyCode.
But in MacOS and JIS-keyboard, Shift+2 and Shift+6 are same keyCode.
So I need mapping using keyIdentifier in MacOS.
I’d like to request to

• (1)in macos, map using keyIdentifier for key-binding in first. In second, using keyCode.
• (2)add isdarwin, iswindows and islinux expressions for Keyboard Rules option when.

I’ll try to code (1).

[alexdima]

@74th the isdarwin, iswindows and islinux are not really needed since the rule in package.json > keybindings can be authored conditional on those already.

Regarding using the keyIdentifier, I cannot make a change that adds support for dispatching on characters (e.g. "@") only on mac. This breaks our cross-OS story.

I think what you really want is a keypress "trap" mode. This would allow to remove many of the keybindings rules in your package.json (such as a, b, shift+a, etc.). Currently, if a keybinding has no rule, it falls through the rule engine that runs on keydown and will therefore produce visible text that gets dispatched to the editor's type command handler.

I am thinking a vim mode would want to "trap" all keybindings producing text and prevent them from reaching the type command, but instead redirecting them to their own command handler. I think everything else is more or less a workaround.

The approach to catch all keybindings is a smart workaround for now, but it is also non-realistic (i.e. would you add in there a rule for ü and all other possible characters)

[74th]

I think there is no need to get all keybindings for my vim extension.
My extension has no keybindings using ctrl, has only single keys or keys added shift.
Because there are no sense to kill vscode functions and other extensions.
But extensions to need them are only vim extensions...

[warpdesign]

+1
Also, not sure if it's related to the same problem, but some shortcuts can be matched by several combinations, and sometimes only one, or worse, none work.

For example: ctrl + * to split the editor

There are two '*' keys on a French keyboard: one above the right shift key, and another one on the keypad, above '9'.

Pressing ctrl+'*' using the keypad '*' key won't work, while using '*' key found above the right shift key will work.

More on that: all shorcuts containing "" won't work on a French keyboard where the "" character cannot be typed directly, but can only be triggered with alt-gr+"\".

[alexdima]

Just pushed a new npm module native-keymap and adopted it in VSCode. It doesn't do anything yet for mac, but it already works for windows and linux.

It kicks in when rendering keybinding labels:

Here is Split Lines when the keyboard layout is set to German (Swiss):

Here is Split Lines when the keyboard layout is set to French (France):

@warpdesign This new rendering (screenshot above) will come out in December and it means "Press Ctrl and the key that when pressed on its own produces *"

[alexdima]

Thanks to @jrieken the labels are also keyboard layout aware on mac

[ForsakenHarmony]

so, what's the status of this now?

[alexdima]

@ForsakenHarmony documented in http://code.visualstudio.com/docs/customization/keybindings#_keyboard-layouts