Some default shortcuts don't work with non-english layout: cmd + ., etc

[jerrygreen]

The What

VSCode should use keywords for hotkey (like [Period]), rather than pure symbols (like .), - for the default key settings that have cmd or ctrl in it.

The Why

So default shortcuts could work universally between all the layouts, so no one has to manually fix those default settings for this purpose.

For example:

• In English layout "Quick Action" shortcut counts as: cmd + ., since . is .
• In Russian layout "Quick Action" shortcut counts as: cmd + ю, but pure symbols (.) don’t count this: ю isn't .
• But if it were cmd + [Period] in setttings, not cmd + ., then it would both count as cmd + . and cmd + ю, - because they're both the same physical key, - which is neat! (Thanks VSCode for having those keywords)

Therefore the default "Quick Fix" action does not work sometimes when you're using other than English layout, so user has to change the layout, which is… Irritating.

Alternatively, user has to fix default hotkeys in settings himself, changing those . to [Period] manually… Which is unfortunate.

The How

TL;DR: Change the default shortcuts so they use the mentioned keywords (like [Period]), instead of pure signs (like .).

As I said, a user can solve each problematic hornet with custom setting like in this example:

// ✅ Good: English layout is respected in whatever currently chosen language in OS
{
  "key": "cmd+[Period]",
  "command": "editor.action.quickFix",
  "when": "editorHasCodeActionsProvider && editorTextFocus && !editorReadonly"
}

This [Period] keyword makes it work throughout different layouts, as long as it shares the same physical key with whatever else symbols in other than English language. But the defaults, it seems, uses the pure symbols:

// ❌ Bad: Although this hotkey works in English layout, however in Russian layout the same (physically) key doesn’t output a dot symbol, thus it doesn’t fire the «Quick Fix» action
{
  "key": "cmd+.",
  "command": "editor.action.quickFix",
  "when": "editorHasCodeActionsProvider && editorTextFocus && !editorReadonly"
}

So hence the problem: VSCode default shortcuts don't work with non-english layout sometimes. This fix (the keywords) should be used throughout all the default keys, in order to solve the issue.

Other problematic shortcuts (examples):

Although I don't know all the concrete examples, there are few ones that I stumbled upon, other than shift + cmd + .:

• cmd + shift + { (shift+cmd+х in Russian layout)
• cmd + shift + } (shift+cmd+ъ in russian layout)

---

Does this issue occur when all extensions are disabled?: Yes

Version: 1.63.2 (Universal)
Commit: 899d46d
Date: 2021-12-15T09:37:28.172Z (1 mo ago)
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0

Formal steps to Reproduce:

1. Using default VSCode settings, hit cmd + . shortcut when using Russian layout
2. See it doesn't work
3. Try cmd + shift + {, cmd + shift + }, - they don't work too

[alexdima]

Thank you for your proposal. We have considered this, but while this might apply with [Period] on the Russian keyboard layout, this doesn't apply across all keyboard layouts. Some immediate examples that come to mind:

• on the German keyboard layout, / is produced via Shift+[Digit7]. Users that use a German keyboard layout expect that toggle line comment is Cmd+Shift+[Digit7], not Cmd+[Slash].
  
• on the French keyboard layout (AZERTY), users expect that select all is Cmd+[KeyQ] and not Cmd+[KeyA].
  
• on the Dvorak keyboard layout, users expect that undo is Cmd+[Slash] and not Cmd+[KeyZ]:
  

[alexdima]

In the meantime, I can try to look into improving our heuristics for layouts like Russian (if there are no keys that produce ., we can add a fallback that [Period] produces . and use [Period] as the physical key for default keybindings involving ., as we already do for all letters A-Z).

IMHO there are two ways to tackle this in:

• either we ship with keyboard layout specific default keybindings (tracked in Support contributing different keybindings based on keyboard layout #1240)
• the community creates extensions that define keymaps suitable for each keyboard layout.

[jerrygreen]

Oh, I see… But why not keep both? I.e.

• cmd + ., - so German/French/Dvorak/etc people can use their language-specific shortcuts

AND, if there no such action, propagate to what I would call "default english hotkey":

• cmd + [Period], - which respects english layout shortcut despite of currently chosen layout

This way you can achieve both, and please both audiences. In the rest some 2% edge cases when there's a conflict with user settings or something, VSCode will respect the language-specific shortcut. Sounds good, isn't it?

Because in my case I don't have any actions on cmd + ю so what happens is: nothing (instead of firing "Quick Fix" action). The same with cmd + shift + х and cmd + shift + ъ, - also nothing (instead of navigating tabs). I'd like them to propagate to their respective english shortcuts in such cases.

P.S. I didn't had this problem for years of using VSCode, because I was always using it purely as code editor, or to writing English documentation, but never needed russian language in VSCode before. Only lately I'm using it to writing russian articles and russian documentation and stuff.

[daniilshustov]

Just stumbled upon broken hotkeys. What was the reasoning for this change?

On a Mac hotkeys doesn’t depend on keyboard layout. Every app opens settings with cmd + . (key code 190) independent of chosen language.

[jerrygreen]

Oh, actually I just re-read my message since then, and find it so confusing by two reasons:

1. Once I accidentally wrote cmd + , instead of cmd + . (now fixed)
2. I had some redundant non-important details (now removed)

So since I edited my original message, can you, please, re-read it, - @daniilshustov and @alexdima?

Additionally, @daniilshustov, - you seem to misinterpret the shortcut. Every app opens settings with cmd + ,, not with cmd + . 😀 So that's key code 188, not 190. But what's important is that VSCode doesn't open it when I have Russian language currently chosen in OS. Which is, as I said originally: unfortunate and irritating. So your statement, @daniilshustov:

On a Mac hotkeys doesn’t depend on keyboard layout

Wrong. Although it is true for other apps, it isn't true for VSCode. That's what this issue is about.

[toramanlis]

I'm not a fan of the logic behind the change, but I could get behind it, if it worked properly. I can't have a shortcut like ctrl+ı but i can have ctrl+alt+ı. A lot of my shortcuts stopped working all of a sudden for some reason. I have no idea why but I have an idea how this could be avoided. Completely eradicate referring the keys with their output. That's exactly what is not in common with different layouts and causes issues. It has never been a good idea and I have never seen it work properly on any app.

It's not just the different layouts. It can be modified at other levels on the OS. I have my Caps Lock on LeftShift+RightShift and the key for Caps Lock works as Alt Gr for example. Best decision of my life by the way. This is set up via KDE. Can you honestly say you account for these type of situations? If I try to use Caps Lock key as Alt Gr or Shift_3 or whatever in a shortcut will you be able to know?

Thank you for your proposal. We have considered this, but while this might apply with [Period] on the Russian keyboard layout, this doesn't apply across all keyboard layouts. Some immediate examples that come to mind:

• on the German keyboard layout, / is produced via Shift+[Digit7]. Users that use a German keyboard layout expect that toggle line comment is Cmd+Shift+[Digit7], not Cmd+[Slash].
  
• on the French keyboard layout (AZERTY), users expect that select all is Cmd+[KeyQ] and not Cmd+[KeyA].
  
• on the Dvorak keyboard layout, users expect that undo is Cmd+[Slash] and not Cmd+[KeyZ]:
  

The German slash example applies to turkish keyboard too. We too have slash at shift+7 and guess what, i can assign ctrl+shift+7 to a shortcut and it doesn't think it's ctrl+/. If you name the key for / on english keyboard [Slash] we will not try to press shift+7 in it's stead. We will know what's going on. In fact, I don't know why are we talking about this like it is not the case already. My ğ key is already referred as [BracketLeft] and it's fine.

Take the letters ı and İ for example. My keyboard has a key that says "I" and one that says "İ" on it. If i press the "I" one whitout shift it types "ı" and the other one types "i". The keys are accent letters depending on if they're capital or not. Now, the shortcut used to identify the "I" one as "ı" and luckily it worked and wasn't affected by the presence of shift in the combination. It stopped working recently. Whereas my "Ğ" key works just fine. Wanna know why? Because it says [BracketLeft] when i set a shortcut with it. It never crossed my mind to press shift+8 to trigger a left bracket while using it.

Yes the french see a Q on their keyboard where it would be named [KeyA]. Big deal. It's just counter-intuitive. I'd very much rather have confusing names for the keys with working shortcuts than having to worry about my layout getting in the way of setting up shortcuts. The names are not for human eye anyway. U can have the "problematic" names in the settings file and the graphical shortcut settings tool can show whatever it types with the current layout. This way it would still be readable even if the layout changes after the shortcuts are set.

Sorry if this is too emotional but I find this an absolute nobrainer and just can't stand still having issues with it. Even after solving them, they reappear. It's keyboard shortcuts. Keys are being mapped to actions. Didn't have to have anything to do with what they'd type. It's just something the keys do apart from this.

[BenjaminGolba]

@toramanlis is on point. I've recently switched between using VSCode on Win, on Mac, on Win on a Mac etc and I have the same issues. Today a previously functional shortcut stopped working

In the keybinding editor I see this when I press cmd+[button to the left of number 1] I see 3 different things:

In the keyboard debugger I get this:

Not sure if it's exactly the same but it seems to be somewhat messy. Now I'm mainly annoyed one of my most used shortcuts stopped working.

[toramanlis]

There seems to be a development on this issue (in both senses). It still relies on the typed character seemingly but there's a fix shipped to insiders:
#173515 (comment)