"""Augmentations to prompt_toolkit's input-parsing tables. Imported once at CLI startup. Each helper installs a small mapping into prompt_toolkit's `ANSI_SEQUENCES` so byte sequences emitted by modern keyboard protocols (Kitty / xterm `modifyOtherKeys`) decode to existing key tuples Hermes already binds. Kept in a standalone module — separate from `cli.py` — so the registrations can be unit-tested without importing the whole CLI runtime. """ from __future__ import annotations def install_shift_enter_alias() -> int: """Map Shift+Enter byte sequences to the (Escape, ControlM) key tuple that Alt+Enter produces, so the existing Alt+Enter newline handler fires for terminals that emit a distinct Shift+Enter. Sequences mapped: - "\\x1b[13;2u" — Kitty keyboard protocol / CSI-u, modifier=2 (Shift) - "\\x1b[27;2;13~" — xterm modifyOtherKeys=2, modifier=2 (Shift) - "\\x1b[27;2;13u" — alternate ordering some emitters use The CSI-u sequence is not in stock prompt_toolkit. The modifyOtherKeys variant `\\x1b[27;2;13~` IS in stock prompt_toolkit but mapped to plain `Keys.ControlM` — i.e. Shift+Enter behaves identically to Enter, which is the very bug this helper exists to fix. We therefore overwrite those two specific keys (and `\\x1b[27;2;13u`) unconditionally; other `\\x1b[27;...;13~` sequences (Ctrl+Enter, Alt+Enter via modifyOtherKeys variants 5/6/etc.) are left untouched. Default macOS Terminal and stock Windows Terminal still send the same byte for Enter and Shift+Enter, so there is no fix for those terminals at the application layer — the sequences above never reach Hermes. Returns the number of sequences whose mapping was changed. """ try: from prompt_toolkit.input.ansi_escape_sequences import ANSI_SEQUENCES from prompt_toolkit.keys import Keys except Exception: return 0 alt_enter = (Keys.Escape, Keys.ControlM) changed = 0 for seq in ("\x1b[13;2u", "\x1b[27;2;13~", "\x1b[27;2;13u"): if ANSI_SEQUENCES.get(seq) != alt_enter: ANSI_SEQUENCES[seq] = alt_enter changed += 1 return changed