Fix logical-character shortcuts on international keyboard layouts

[jfaltermeier]

What it does

Fixes #13874.

Problem

Printable shortcuts previously mixed up command modifiers with modifiers needed by the active keyboard layout to produce a character.

On a German layout, [ is produced by AltGr+8. This caused two related failures:

• Recording Ctrl+[ saved Ctrl+8.
• Manually authoring ctrl+[ displayed and triggered as Ctrl+Ü, following the US BracketLeft position instead of the logical [ character.

As a concrete walkthrough, assign ctrl+[ to chat:open-claude-code-memory. This command has no default keybinding and is easy to use/verify.

Solution

The new flow keeps authored command modifiers (Ctrl, Alt, Shift, and Meta) separate from layout-production modifiers (Shift, AltGr, or both):

1. KeyCode parsing preserves the authored logical character. Authored serialization remains separate from the stable runtime dispatchString() identity. [ScanCode] and [char:...] provide explicit physical and reserved-character forms.
2. KeyboardLayoutService resolves German [ to physical Digit8 on the AltGr layout layer and derives platform-specific interpretations of normalized keyboard input.
3. KeybindingRegistry resolves and caches bindings, matches normalized interpretations by runtime identity, prioritizes intentional command-modifier interpretations where necessary, and executes the selected command.
4. The Keyboard Shortcuts editor records and displays ctrl+[ / Ctrl+[, while its tooltip exposes Ctrl+AltGr+8 as the physical realization.

Concept	Before	After
Authored binding	ctrl+[	ctrl+[
Logical character	Mixed up with US BracketLeft	[
German physical realization	Ctrl+Ü or recorded Ctrl+8	Digit8 + AltGr, with authored Ctrl
Display	Ctrl+Ü / Ctrl+8	Ctrl+[
Runtime event	Unreliable	Ctrl+AltGr+8 matches the stable dispatch identity

Other affected areas

The logical/physical distinction now consistently applies to:

• choosing the correct shortcut when one key press could match several shortcuts;
• updating shortcuts when the keyboard layout or related settings change;
• showing shortcuts that are not available on the current keyboard layout as inactive;
• recording shortcuts and showing which physical keys must be pressed;
• showing shortcuts correctly in browser and plugin menus;
• showing only shortcuts supported by Electron in native menus;
• handling shortcuts correctly in the Monaco editor;
• passing keyboard input correctly from plugin webviews, including AltGr;
• running shortcuts from code.

Compatibility and migration

Existing keymaps.json files and keybinding strings remain parseable. No file-format migration is required.

Printable tokens now follow logical characters. Position-dependent bindings must use scan-code syntax such as ctrl+[BracketLeft]. Reserved logical characters use character tokens such as ctrl+[char:0x2B].

Logical characters unavailable on the active layout remain visible but inactive instead of falling back to an unrelated US key position. Users who require global positional behavior can set:

"keyboard.dispatch": "keyCode"

Downstream adopters must:

• migrate KeyboardLayout.key2KeyCode consumers to candidatesByCharacter or candidatesByFoldedCharacter;
• move overrides of the removed transformKeyCode() and getCharacterIndex() extension points to resolveKeyCode() and candidate lookup;
• pass normalized input to KeyboardLayoutService.validateKeyCode;
• review KeyCode equality, modifier-only checks, authored serialization, and runtime dispatchString() usage;
• update matchKeybinding() consumers from match.binding to match.runtime.binding;
• adapt protected chord and keybinding-tree consumers to candidate sequences and runtime records;
• pass an explicit logical or physical form to AcceleratorSource.getAccelerator.

See packages/keymaps/README.md for the complete keybinding grammar and doc/Migration.md for adopter details.

How to test

I guess we have to test setting up and using keyboard shortcuts on different OSes with various keyboard layouts and throughout the application. Maybe testing via next builds would be suitable.

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines