You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Windows, with Czech layout, somehow migrates binding to Ctrl+ú:
macOS with Czech layout drops the particular binding:
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.
The text was updated successfully, but these errors were encountered:
Does this issue occur when all extensions are disabled?: No, though the extension is needed just to expose VSCode behavior.
Using
neovim-vscode
extension (v1.18.16) on both macOS and Windows. The extension defines a keybinding in itspackage.json
forctrl+[
this way:When used with
US
keyboard layout, in both systems, it works as expected:ctrl+[
gets caught by VSCode and translated tovscode-neovim.escape
command.When used with
Czech
keyboard layout (which is calledCzech
in both Windows and macOS) the behavior differs in a way that in Windows version, the keyboard binding is automatically "migrated" to usingCtrl+ú
as an input (which is physically the same key on Czech keyboard - i.e. the one right toP
), but on macOS the binding disappears.Visualized keyboard bindings for
US
keyboard looks the same in both, macOS and Windows:Windows, with
Czech
layout, somehow migrates binding toCtrl+ú
:macOS with
Czech
layout drops the particular binding:Keyboard log from Windows (with
Czech
layout) when pressingCtrl+ú
:while from macOS:
I noticed than in Windows VSCode resolves the key press to
ctrl+[
(which is correct interpretation), while usingBracketLeft
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 tokeyCode: 92
, but apparently advertises it asctrl+[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:
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 somehowctrl+[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+[
toCtrl+ú
, even when the extension, which defines the binding, is using onlyctrl+[
in its definition.The text was updated successfully, but these errors were encountered: