mirror of
https://github.com/stablyai/orca.git
synced 2026-09-22 00:02:31 +00:00
* fix(terminal): forward Windows Ctrl Alt chords * fix(terminal): route rescued Windows Ctrl+Alt chords through xterm's own key encoders Replace the hand-rolled Alt-prefix encoder in the custom key handler with a narrow repair of xterm's third-level-shift classification. xterm's keyboard service already computes the correct bytes for every input protocol (legacy ESC-prefixed, kitty CSI-u, win32-input-mode) before _isThirdLevelShift discards them on Windows Ctrl+Alt; rescuing only provably-genuine chords (Chromium's layout-wide AltGraph simulation, crbug 762557) lets those encoders deliver protocol-correct, layout-aware bytes with no duplicated encoding knowledge in Orca. Fixes vs the previous approach: kitty-mode TUIs now receive CSI-u instead of legacy bytes, digits/punctuation no longer alias to plain Alt chords, letters follow the logical layout (Dvorak/Colemak), Ctrl+Alt+Shift and Ctrl+Alt+F-keys gain Linux parity, and handled keys get xterm's stock preventDefault/stopPropagation. Firefox web clients keep stock behavior; a real-Terminal contract test fails loudly if an xterm upgrade removes the seam, degrading at runtime to the historical dropped-chord behavior. Co-authored-by: Orca <help@stably.ai> * Refactor Windows Ctrl+Alt chord test helpers and clarify AltGraph commen - Extract a shared getCore() helper in the test file to dedupe repeated `_core` casts across third-level-shift and keyboard-service lookups. - Correct the AltGraph comment: Chromium simulates AltGraph per composing keypress, not for the whole Ctrl+Alt press duration. - Warn via console when xterm no longer exposes `_core._isThirdLevelShift`, so a silent classification-repair failure is diagnosable in the wild. * Clarify comment explaining why Windows Ctrl+Alt chords bypass AltGraph c The comment previously implied Chromium always sets AltGraph=true for composable chords; the revised wording states the actual mechanism (Alt+Ctrl modifiers get replaced by AltGraph) so the inverse case is unambiguous. --------- Co-authored-by: Jinjing <6427696+AmethystLiang@users.noreply.github.com> Co-authored-by: Orca <help@stably.ai>