Support `! <command>` and `!command` in the TUI composer to run shell commands through the existing exec_shell path.
The shortcut keeps normal approval, sandbox, policy, transcript, and work-panel handling, while avoiding model context
pollution from local-only tool results.
Refs #1546
Closes#1359. On Windows 11 + VSCode integrated terminal +
PowerShell, pressing `Shift+Enter` in the composer submitted the
message instead of inserting a newline. `Alt+Enter` / `Ctrl+J`
were broken the same way. Root cause: crossterm's
`PushKeyboardEnhancementFlags` checks `is_ansi_code_supported()`
before emitting the escape, and on Windows that helper queries
the console mode rather than the VT capability and
unconditionally returns false — so the Kitty push `\x1b[>1u` was
never written. xterm.js then stayed in legacy mode where
`Shift+Enter` and `Enter` both encode as `\r`, indistinguishable.
The fix writes the push and pop escapes directly under
`#[cfg(windows)]`, bypassing the crossterm capability gate.
VSCode and Windows Terminal honour the Kitty keyboard protocol;
terminals that don't (older conhost without VT processing)
silently discard the unknown escapes. The same gate also meant
`PopKeyboardEnhancementFlags` was silently dropped on Windows in
the `main.rs` panic hook and in
`tui::external_editor::spawn_editor_for_input` — both call sites
now route through `pop_keyboard_enhancement_flags` so a crash or
`$EDITOR` invocation can't leave the parent shell with a
Kitty-enhanced keyboard state.
Two `#[cfg(windows)]` regression tests pin the direct-write path
so accidentally falling back to `execute!()` against
`crossterm::PushKeyboardEnhancementFlags` would now fail in CI:
- `push_keyboard_flags_writes_kitty_push_sequence_on_windows`
- `pop_keyboard_flags_writes_kitty_pop_sequence_on_windows`
Non-Windows behaviour is unchanged — the existing
`recover_terminal_modes_emits_expected_csi_sequences_with_gating`
test still passes on Linux and macOS.
Also adds a v0.8.29 audit note to `docs/KEYBINDINGS.md` and
documents a pre-existing FocusGained stack-depth bug for a
separate fix.
Harvested from PR #1483 by @CrepuscularIRIS
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Fix Ctrl-S: stash current draft, not reverse history search
- Add Alt-R: search prompt history
- Note bare Up/Down arrows now scroll transcript when composer is empty (v0.8.13)
- Remove phantom Alt+Up from audit notes
- Note tui.toml wiring still deferred
- Remove dated 'v0.8.11 follow-up' reference in header
Walks every key handler in `crates/tui/src/tui/ui.rs` and
`crates/tui/src/tui/app.rs`, confirms each chord resolves to a live
action, and groups them by context (global, composer, transcript,
sidebar, palette, approval modal, onboarding) so users have a single
page to point at instead of guessing from the help overlay.
Audit findings inline at the bottom of the doc:
* No broken bindings: every chord resolves to a live handler.
* `Ctrl-P` was previously double-bound (history + palette); that's
reconciled — the palette opens via `Ctrl-K`, `Ctrl-P` keeps history.
* The `?` help overlay entries all correspond to bindings in the
catalog; aspirational ones were either implemented this release or
dropped.
Deferral note for #436 (configurable keymap) and #437 (separate
`tui.toml`): both need a named-binding registry that names every chord
on this page and lets a user file override individual entries with
conflict detection. Half-implementing that in a patch release is worse
than landing the spec first; v0.8.10 ships the spec, the registry
follows in v0.8.11.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
reidliu41