Neil b6d36c26f4 fix(terminal): resolve Ctrl chords positionally on a non-Latin layout (#14469) ...

macOS maps a control chord by physical key regardless of layout: measured with
UCKeyTranslate, physical A/U under Control produce U+0001/U+0015 on 2SetHangul,
Russian and Greek exactly as on ABC, though unmodified those keys give ㅁ/ㅕ,
ф/г, α/θ. A native terminal inherits this by passing the OS characters through.

The browser does not expose that translation. xterm's legacy encoder works
anyway because it reads keyCode, which Chromium reports from the physical key,
but its kitty encoder derives the key number from `key` and only consults
`code` when Shift or Option is held. Ctrl is not in that gate, so a pane with
the kitty protocol negotiated reports CSI-u for U+3141 rather than 'a' and the
chord does nothing. Ctrl+C escaped this only via its hand-written ETX bypass.

Recover the byte from `code` when `key` is non-ASCII, which reproduces the
OS control table. An ASCII `key` stays authoritative so a Dvorak remap is
honoured. KeyC is excluded: the interrupt policy owns it, and off macOS that
policy declines to a selection so the copy binding wins.

Fixes #13331

2026-08-14 00:02:53 -07:00

..

src

fix(terminal): resolve Ctrl chords positionally on a non-Latin layout (#14469)

2026-08-14 00:02:53 -07:00

index.html

fix(macos): prevent stale UI surfaces after wake (#11226)

2026-07-28 16:37:13 -07:00

popout.html

fix(macos): prevent stale UI surfaces after wake (#11226)

2026-07-28 16:37:13 -07:00

web-index.html

…