fix(tui): enable Kitty keyboard protocol on Windows so Shift+Enter inserts newline
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>
This commit is contained in:
@@ -99,6 +99,10 @@ When `[memory] enabled = true`, typing `# foo` and pressing `Enter` appends `foo
|
||||
| `y` / `Y` | Trust the workspace (Trust step) |
|
||||
| `n` / `N` | Skip the trust prompt |
|
||||
|
||||
## v0.8.29 audit notes
|
||||
|
||||
- **`Shift+Enter` / `Alt+Enter` newlines now work in VSCode on Windows (#1359).** crossterm's `PushKeyboardEnhancementFlags` command unconditionally returns `Unsupported` on Windows (`is_ansi_code_supported() == false`), so the Kitty keyboard protocol escape was never written to the terminal. Without it, VSCode's xterm.js stays in legacy mode where `Shift+Enter` is indistinguishable from plain `Enter`, causing the composer to send the message instead of inserting a newline. The fix writes the push/pop escapes (`\x1b[>1u` / `\x1b[<1u`) directly on Windows, bypassing crossterm's capability gate. VSCode integrated terminal and Windows Terminal ≥1.17 both honour the Kitty keyboard protocol; terminals that do not understand the sequences silently discard them.
|
||||
|
||||
## v0.8.13 audit notes
|
||||
|
||||
- **Ctrl-S is stash, not history search.** Fixed in this revision — `Alt-R` is history search.
|
||||
|
||||
Reference in New Issue
Block a user