diff options
| author | Craig Jennings <c@cjennings.net> | 2026-06-13 00:56:38 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-06-13 00:56:38 -0500 |
| commit | a631938c95ee7974a1d5489ad3aba713c4f0a0d5 (patch) | |
| tree | b0e9fe7b88fa3f0707f4787429cbf2554a2a91af /scripts/theme-studio | |
| parent | 2cc54965d614151c8d8df7c0c857cbcd4aedf1af (diff) | |
| download | dotemacs-a631938c95ee7974a1d5489ad3aba713c4f0a0d5.tar.gz dotemacs-a631938c95ee7974a1d5489ad3aba713c4f0a0d5.zip | |
fix(keys): revert 4a1ecf64, restore the M-S- launcher bindings
4a1ecf64 rebound eww/elfeed/calibredb from M-S-e/r/b to the uppercase Meta events M-E/M-R/M-B, on the theory that the keyboard emits the uppercase event and the lowercase-shift spec never matched. It was wrong. keyboard-compat.el installs a key-translation-map entry (M-E -> M-S-e, etc.) in GUI frames, so the original M-S- bindings did reach the launchers. Binding M-E directly while that translation stayed in place rewrote the keypress to the now-unbound M-S-e, breaking all three in GUI on the next restart.
The audit and the review missed it because they checked key-binding, which ignores key-translation-map, and the running daemon still held the pre-fix bindings as stale state.
This restores M-S-e/r/b, deletes the key-binding-only test that certified the broken config, and reclassifies the task as not-a-bug. The real problem, that these chords are dead outside GUI, is the subject of the keybinding-console-safety spec.
Diffstat (limited to 'scripts/theme-studio')
0 files changed, 0 insertions, 0 deletions
