Support contributing different keybindings based on keyboard layout

[weinand]

VSCode should ship out of the box with multiple keymaps (based on/optimized for each keyboard layout).
e.g. toggle line comment should be ctrl+7 on swiss keyboards, etc.

VSCode should detect at runtime the current system keyboard layout and employ different defaults, based on the keyboard layout.

[bpasero]

Hm it should be...

[bpasero]

So Cmd++ works for me, which is cool. However what is weird is that we set the keybinding like this:

{ primary: KeyMod.CtrlCmd | KeyCode.US_EQUAL }

I could not find KeyCode.US_PLUS.

@alexandrudima can you comment on this maybe?

[weinand]

@bpasero does Cmd++ work for you on a non-US keyboard?

[bpasero]

@weinand yes I am on german keyboard layout (ibm) and interestingly when I type "Cmd++" into the keyboard widget, I see it prints Cmd+= for me. What does it print for you?

[weinand]

@bpasero I'm on a Swiss German keyboard and I see "shift+cmd+=" and I know where the '=' comes from. On a US keyboard the '+' and the '=' are together on a key and since we only have KeyCode constants for the unshifted key, it is KeyCode.US_EQUAL.

@bpasero restating my question from above: did Cmd++ work for you without changing the keybinding?

[bpasero]

@weinand yes always worked for me without changing anything. and I see that we did not change this keybinding in months.

[weinand]

@bpasero yes, it worked for you because on a German keyboard the '+' doesn't require a 'Shift' modifier. For a Swiss-German keyboard it never worked.

[bpasero]

@weinand that is odd, I leave it to @alexandrudima if we can provide the keybinding that works for Swiss and other keyboard layouts, but we might be limited here because we cannot express per-language keybindings.

[weinand]

@bpasero after discussions with @alexandrudima I now better understand the issues around this problem and yes, we came to the same conclusion that we can only solve the issue with keyboard layout specific keybindings.

[patrys]

I think it's maybe time to revive this issue. A number of other issues have been merged into this one including a lot of issues about languages that depend on AltGr. Now AltGr is a technique that gives one or both Alt a special function of switching to a secondary keyboard layout group.

Polish for example depends on AltGr to to switch between naked characters and accented ones. Pressing Z gives you Z while pressing Alt+Z gives you Ż. Polish diacritics are not otherwise available as separate keys (long story short: there used to be a Polish typist keyboard layout and typewriters used it but we had to import computers with US keyboards because communism).

Now Alt+Z from the example above is currently mapped to "toggle word wrap". This means we can't type in Polish without remapping parts of the keyboard.

[alexdima]

@patrys On mac we ship with 516 default keybindings. There are hundreds of possible keyboard layouts only on the mac and it is possible for people to customize them and create their own keyboard layouts.

It is difficult to find key combinations which are both easy enough to be remembered, easy enough to be ergonomically feasible and which work across a wide number of the keyboard layouts well.

The correct fix for your case is for VS Code to ship with Alt+Z as the keybinding for toggle word wrap for every keyboard layout except the Polish one, under which Alt+Z should be kept free such that Ż can be produced. So issue #50053 is indeed a duplicate of this issue.

[Tekbr]

-- Sorry for the English, I used Google Translator --

I know the team has put a lot of resources into the VSCode. So much that it has much prominence in Windows, OS X and Linux and in several languages and not only in English.

And because of this dimension, I think you can already pay attention to Keyboard Layout for a variety of languages. Regardless of the number of votes. As I see it is a trivial resource. It already has a lot of other cases related precisely because of this problem.

It is very bad you look for a certain type of shortcut (which is in US standard) and when using in your layout (in my case PT-BR2) it does not match or be seen otherwise.

This affects both the VSCode and the extensions used in it.

But I want to congratulate the team for their great work.

Thanks for the attention.

// ping @alexandrudima

[jrpub]

Refering to #32473 (which has been closed), to open terminal on many french laptops:

ctrl + ù

Sorry if it has been already disclosed, I didn't read everything, just wanted to put the tips.

[kingma-sbw]

It is possible to find the key bindings under
File, Preferences, Keyboard shortcuts.

What is annoying is that Help, Keyboard Shortcuts Reference points to a pdf that has no relation to the actual key bindings. Keybindings depend on the language. The PDF should state its specific validity for US American Keyboard layout.

[fleps]

I have a small programable keyboard that uses BootMapper Client to setup keybinds. It's configured to send the normal extra "F" keys tradicional keyboards don't have like F20, 21, 22, 23, 24, which are all valid keys.
For some reason VSCode does not detect these keys (but any other software does)

If I try to use the F20 key, what I get is an "unknown"
Using the debugger, I get this:

/ Received keydown event - modifiers: [], code: F20, keyCode: 131, key: F20
| Converted keydown event - modifiers: [], code: F20, keyCode: 0 ('unknown')
\ Keyboard event cannot be dispatched in keydown phase.

If I use other keys like F12, this doesn't happen, even if I program the F12 to come from the macro keyboard.

Why VSCode just don't use the KeyCode? Why does it need to "convert" it??

It seems we had a setting in the past that fixed this on Windows ( "keyboard.dispatch": "keyCode" ) but now this setting is not valid anymore.

Again, why? Why overcomplicate such a simple thing for valid keyCodes that exist since forever?

[Lemmingh]

I guess I get your idea now. The "F20" case seems to be an issue from Chrome.

https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code/code_values

vscode/src/vs/workbench/services/keybinding/common/windowsKeyboardMapper.ts

Line 619 in 7122249

VK_F20: KeyCode.Unknown, // MISSING

[ajmas]

On the Mac using the option key, without the command key is problematic as it prevents the use of the alternative characters, that are only accessible when holding down the option key.

Using the control key is probably less bad, but it should be noted that certain combinations, such as ctrl-A, correspond to emacs style keyboard navigation that works in all text fields.

For example, I use a US keyboard, but being in a multilingual environment will sometimes needs to add an accent. These accents are available via the option key. The full range of characters available can be seen via the virtual keyboard. My workaround is to not use VS Code when I need to write things that need the full keyboard, since remapping all the VS Code short cuts is just too tedious.