Incorrect rendering of key bindings with Spanish keyboard on linux

[mtrivolli]

According to the documentation, vscode renders the key bindings using the system keyboard layout.
But in my case, the rendered key bindings do not seem to correspond to my layout.

For instance, the split command is shown to be ctrl + ç, however that combination toggles a line comment.

The toggle line comment is shown to be ctrl + -, but such combination reduces the font size.

The output of localectl status is:

   System Locale: LANG=es_ES.UTF-8
       VC Keymap: n/a
      X11 Layout: es
       X11 Model: pc102
     X11 Options: compose:ralt,terminate:ctrl_alt_bksp

[alexdima]

I have validated that we now (i.e. after PR #22894 aka #17521 -- in tomorrow's Insiders build) appear to behave correctly for this keyboard layout

---

Analysis of default keybinding for editor.action.commentLine

• editor.action.commentLine is bound by default to the key code binding ctrl+/
• / can be produced through one scan code combination: Shift+[Digit7]. i.e.:
  
• The key code binding ctrl+/ is therefore mapped to the scan code binding Ctrl+Shift+[Digit7] and the F1 command picker now correctly reflects that:
  
  
• That is unfortunate, but correct. We don't ship with keyboard layout specific default keybindings, that is something you can upvote in Support contributing different keybindings based on keyboard layout #1240

---

Analysis of default keybinding for workbench.action.splitEditor

• workbench.action.splitEditor is bound by default to the key code binding ctrl+\
• \ can be produced through three scan code combinations: Ctrl+Alt+[Minus], Ctrl+Alt+[Backquote] and Ctrl+Alt+Shift+[Backquote]. i.e.:
  
• because Ctrl must be used to produce the visual character, the key code binding ctrl+\ is not mappable . i.e. the scan code combo would need to be something like Ctrl+ Ctrl+Alt+[Minus], which we don't support.
• therefore, the action is unbound by default. That is unfortunate, but correct.

---

This makes me believe the fix in PR #22894 aka #17521 resolves this issue. Please double check in tomorrow's insiders build.