Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keybindings different behavior in Windows and macOS with Czech localized keyboard layout #237533

Open
risa2000 opened this issue Jan 8, 2025 · 0 comments
Assignees

Comments

@risa2000
Copy link

risa2000 commented Jan 8, 2025

Does this issue occur when all extensions are disabled?: No, though the extension is needed just to expose VSCode behavior.

  • VS Code Version: 1.96.2
  • OS Version: macOS, Sonoma v14.7.2, Windows 10 Pro, 22H2

Using neovim-vscode extension (v1.18.16) on both macOS and Windows. The extension defines a keybinding in its package.json for ctrl+[ this way:

{
    "command": "vscode-neovim.escape",
    "key": "ctrl+[",
    "when": "editorTextFocus && neovim.init && editorLangId not in neovim.editorLangIdExclusions"
}

When used with US keyboard layout, in both systems, it works as expected: ctrl+[ gets caught by VSCode and translated to vscode-neovim.escape command.

When used with Czech keyboard layout (which is called Czech in both Windows and macOS) the behavior differs in a way that in Windows version, the keyboard binding is automatically "migrated" to using Ctrl+ú as an input (which is physically the same key on Czech keyboard - i.e. the one right to P), but on macOS the binding disappears.

Visualized keyboard bindings for US keyboard looks the same in both, macOS and Windows:
Image

Windows, with Czech layout, somehow migrates binding to Ctrl+ú:
Image

macOS with Czech layout drops the particular binding:
Image

Keyboard log from Windows (with Czech layout) when pressing Ctrl+ú:

2025-01-09 00:01:18.989 [info] [KeybindingService]: / Soft dispatching keyboard event
2025-01-09 00:01:19.004 [info] [KeybindingService]: \ Keyboard event cannot be dispatched
2025-01-09 00:01:19.005 [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control
2025-01-09 00:01:19.005 [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl')
2025-01-09 00:01:19.005 [info] [KeybindingService]: \ Keyboard event cannot be dispatched in keydown phase.
2025-01-09 00:01:19.255 [info] [KeybindingService]: / Soft dispatching keyboard event
2025-01-09 00:01:19.255 [info] [KeybindingService]: | Resolving ctrl+[
2025-01-09 00:01:19.255 [info] [KeybindingService]: \ From 2 keybinding entries, matched vscode-neovim.escape, when: editorTextFocus && neovim.init && editorLangId not in 'neovim.editorLangIdExclusions', source: user extension asvetliakov.vscode-neovim.
2025-01-09 00:01:19.255 [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: BracketLeft, keyCode: 219, key: ú
2025-01-09 00:01:19.255 [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: BracketLeft, keyCode: 92 ('[')
2025-01-09 00:01:19.255 [info] [KeybindingService]: | Resolving ctrl+[
2025-01-09 00:01:19.255 [info] [KeybindingService]: \ From 2 keybinding entries, matched vscode-neovim.escape, when: editorTextFocus && neovim.init && editorLangId not in 'neovim.editorLangIdExclusions', source: user extension asvetliakov.vscode-neovim.
2025-01-09 00:01:19.255 [info] [KeybindingService]: + Invoking command vscode-neovim.escape.
2025-01-09 00:01:19.677 [info] [KeybindingService]: + Ignoring single modifier ctrl due to it being pressed together with other keys.

while from macOS:

2025-01-09 00:04:27.995 [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control
2025-01-09 00:04:27.996 [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl')
2025-01-09 00:04:27.996 [info] [KeybindingService]: \ Keyboard event cannot be dispatched in keydown phase.
2025-01-09 00:04:28.190 [info] [KeybindingService]: / Received  keydown event - modifiers: [ctrl], code: BracketLeft, keyCode: 219, key: ú
2025-01-09 00:04:28.194 [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: BracketLeft, keyCode: 92 ('[')
2025-01-09 00:04:28.194 [info] [KeybindingService]: | Resolving ctrl+[BracketLeft]
2025-01-09 00:04:28.194 [info] [KeybindingService]: \ No keybinding entries.
2025-01-09 00:04:28.533 [info] [KeybindingService]: + Ignoring single modifier ctrl due to it being pressed together with other keys.

I noticed than in Windows VSCode resolves the key press to ctrl+[ (which is correct interpretation), while using BracketLeft as the internal code, which is apparently enough to match the defined key binding.
Contrary to that, in macOS VSCode detects the same key identified by the keyCode: 219 and then translated to keyCode: 92, but apparently advertises it as ctrl+[BracketLeft], which does not match the extension defined bindings and is therefore missed.

I tried to fix the issue by redefining the binding in the extension to:

{
    "command": "vscode-neovim.escape",
    "key": "ctrl+[BracketLeft]",
    "when": "editorTextFocus && neovim.init && editorLangId not in neovim.editorLangIdExclusions"
}

which seems to be working correctly in both OSes and both keyboard layouts. The key parsing on Windows is exactly the same with Resolving ctrl+[, yet somehow ctrl+[BracketLeft] binding is correctly triggered. On macOS the binding is triggered because it is resolved to the exact same key input (ctrl+[BracketLeft]).
But I wonder, why is there this discrepancy in the key code interpretation between macOS and Windows and whether my fix is actually sane, because from the screenshots I posted above, it seems VSCode does know (at least on Windows), how to "migrate" Ctrl+[ to Ctrl+ú, even when the extension, which defines the binding, is using only ctrl+[ in its definition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants