mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-05-09 03:11:58 +00:00
f5b635f6ab
Closes #5346. Most terminals send the same byte sequence for `Enter` and `Shift+Enter` by default, so the application can't tell them apart — this is a terminal protocol limitation, not something Hermes can paper over. But terminals that implement the Kitty keyboard protocol (Kitty / foot / WezTerm / Ghostty by default; iTerm2 / Alacritty / VS Code terminal / Warp once the protocol is enabled) DO emit a distinct sequence for `Shift+Enter`: - `\x1b[13;2u` — Kitty / CSI-u, modifier=2 - `\x1b[27;2;13~` — xterm modifyOtherKeys=2 Stock prompt_toolkit doesn't have the CSI-u sequence in its `ANSI_SEQUENCES` table at all, and it maps the modifyOtherKeys variant to plain `Keys.ControlM` (Enter) — i.e. it strips the Shift modifier, which is the bug users actually hit on iTerm2 and friends. This PR adds `hermes_cli/pt_input_extras.install_shift_enter_alias()`, called once at CLI startup from `cli.py`, which inserts/overwrites those sequences in `ANSI_SEQUENCES` so they decode to `(Keys.Escape, Keys.ControlM)` — the same key tuple `Alt+Enter` produces. The existing Alt+Enter newline handler (`@kb.add('escape', 'enter')` in `cli.py`) then fires unchanged, so there is no new keybinding to register and no behavioral change for terminals that don't emit the distinct sequences. Files ===== * `hermes_cli/pt_input_extras.py` — new module hosting the helper. Lives outside `cli.py` so it's importable in tests without dragging in the full CLI runtime (which depends on `fire`, `rich`, etc.). * `cli.py` — calls `install_shift_enter_alias()` once at module import. Wrapped in try/except so prompt_toolkit version drift can't break CLI startup. * `tests/cli/test_cli_shift_enter_newline.py` — 6 tests: - registration of all three byte sequences - overwrite of stock prompt_toolkit's broken modifyOtherKeys mapping - idempotency - parser equivalence: CSI-u Shift+Enter == Alt+Enter - parser equivalence: modifyOtherKeys Shift+Enter == Alt+Enter - plain Enter remains a single key (submit), distinct from the two-key Alt+Enter / Shift+Enter tuple * `website/docs/user-guide/cli.md` — keybinding table updated; new "Shift+Enter compatibility" subsection with a per-terminal status table noting macOS Terminal / stock Windows Terminal cannot distinguish the keystroke at the protocol level. * `website/docs/getting-started/quickstart.md`, `website/docs/guides/tips.md` — short mention pointing readers at the full compatibility note in `cli.md`. Tested ====== pytest tests/cli/test_cli_shift_enter_newline.py # 6 passed Live-tested by triggering `\x1b[13;2u` against the running Vt100Parser (see test). Not exercised in a real terminal end-to-end because that requires a Kitty-protocol-capable host; the test exercises the parser path that drives the live terminal too.
51 lines
2.1 KiB
Python
51 lines
2.1 KiB
Python
"""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
|