sublimehq
Keybindings use hardware scan codes instead of layout-translated key values (mod+Fn inconsistencies)
Description of the bug
When binding keyboard shortcuts, the application appears to use raw keyboard scan codes instead of the values returned by the active keyboard layout (via XKB/Wayland).
This causes inconsistent behavior when custom layouts or modifier mappings are in use. For example, on my Linux system:
mod+F1 works correctly as a shortcut. mod+F2/F3/F4/F5 don't trigger, even though the layout reports it as a valid keysym. the key combinations shift+mod+F1 also works, but not shift+mod+F2...F5 mod+F5 and shift+mod+F5 appear to trigger gdb like without the mod key. the key combinations altrgr+mod+Fx and altgr+shift+mod+Fx work properly, for all x.
Other applications (e.g. terminal emulators) respect the layout correctly, so the issue seems specific to this application’s input handling.
Steps to reproduce
- under linux/X11, copy+rename the attached layout in the right directory:
sudo cp eurkey_mirror.txt /usr/share/X11/xkb/symbols/eurkey_mirror - activate the layout with:
setxkbmap -layout "eurkey_mirror" -option - the modifier key is the spacebar. to type a space character, press spacebar+winkey
- as per layout, spacebar+F1..F5 should produce
=-]['and shift+spacebar+F1..F5 should produce+_}{",but only the F1-combinations work
this keyboard layout is for left-hand-only typing, for freeing the right hand for mouse or tablet, or for single-handed people.
Expected behavior
as per layout attached above, spacebar+F1..F5 should produce =-][' and shift+spacebar+F1..F5 should produce +_}{"
Actual behavior
spacebar+F2..F4 and shift+spacebar+F2...F4 don't trigger any key, spacebar+F5 triggers like F5 alone (in my case a different layout from the GDB plugin) and shift+spacebar+F5 like shift+F5 triggers the GDB output window (in my configuration).
Sublime Text build number
Sublime Text Build 4200
Operating system & version
ArchLinux, kernel 6.16.3-zen1
(Linux) Desktop environment and/or window manager
Gnome, X11
Additional information
No response
OpenGL context information
That's how ST is designed to work. It uses hardware scan codes expectating to map commands to physical keys.
It actually even causes key bindings to not map to same keys accross OS's (e.g. Linux/Windows) using same language.
related: #1341, #4379, #4979, #5980, #6507
