umputun / agterm / 30399924719

98%

push

github

fix: resolve keymap chords by keyboard layout instead of produced character

keybinds defined in `keymap.conf` did nothing on a non-English keyboard layout. Custom commands and ⌘Z undo-close are delivered by `NSEvent` monitors that matched the character the active layout produces, so on a Cyrillic layout the physical O key yields `щ` and a Latin-spelled `cmd+o` could never match. Built-in `map` shortcuts were unaffected, they ride AppKit menu key equivalents, a different mechanism.

the chord now resolves per **layout**, not per key, from the input source's ASCII-capable property. A layout that can type ASCII (US, Dvorak, Colemak, US-International, French, German) binds the character it produces, exactly as before, so no existing binding changes. A layout that cannot (every Russian variant, Greek, Hebrew, Arabic, Thai) binds every key by physical position through the ANSI table. The property is read fresh on each key press, ~0.22 µs, so there is no cache to go stale.

deciding per key instead, keeping any produced character that happens to be ASCII, does not work. Greek types `;` on the physical Q and Hebrew types `/` there, so letter chords stayed dead on two of the three layouts this targets. It also let two physical keys resolve to one chord, firing a binding from a key the user never pressed and swallowing the keystroke. The ISO section key is dropped on a position-resolved layout for the same reason, Ukrainian-PC types `\` there and the ANSI backslash key already owns it.

`undo_close` (⌘Z, File ▸ Reopen Closed Item) had the same defect and is fixed with it. Nobody reported that one.

the `ghostty.conf` half of the report is *not* an agterm bug. A bare letter there is a ghostty unicode trigger matched against the produced character, `key_g` is a physical trigger. Verified identical in the pinned libghostty and on ghostty `main`, and agterm builds the key event exactly as Ghostty.app does, so it is documented rather than changed. The bundled defau... (continued)

64 of 64 new or added lines in 1 file covered. (100.0%)

6313 of 6448 relevant lines covered (97.91%)

4662863.05 hits per line