feat: make Shift+Enter insert a newline by enabling terminal key modes - #20
Conversation
The chatbox already maps the Kitty (ESC [ 13 ; 2 u) and modifyOtherKeys (ESC [ 27 ; 2 ; 13 ~) Shift+Enter sequences to c-j/newline, but lecode never asked the terminal to send them, so Shift+Enter submitted the prompt on terminals that need explicit enablement. TuiApp.run() now pushes the Kitty keyboard-protocol disambiguate flag (CSI > 1 u) and xterm modifyOtherKeys level 1 (CSI > 4 ; 1 m) on start, and restores both on exit. Skipped on non-tty stdout, TERM=dumb, and Windows; terminals without support ignore the sequences.
|
Confirmed by testing the installed PR commit Reproduction on a terminal supporting the Kitty protocol:
Please support the CSI-u encodings of the existing controls before enabling this mode, and add regression coverage for Ctrl-C cancellation/clearing and the other affected shortcuts. The current tests supply legacy shortcut bytes, so they do not catch this regression. Relevant code: Line 201 in 90506f0 Protocol reference: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#disambiguate-escape-codes |
Problem
Shift+Enter arrived as plain Enter in terminals that require keyboard mode enablement, so it submitted the prompt instead of inserting a newline. Enabling those modes also changes other keys: the original PR made Kitty Ctrl-C insert
[99;5uinto the composer, and xterm level 1 did not report Shift+Enter distinctly.Fix
TERM=dumb, and Windows.Validation
tests/test_tui_streaming_pty.py: 16 passed.test_tui_app.pyrun is not green: generated-prompt hook cases fail, andtest_pipe_ctrl_c_exits_cleanlypasses but hangs after the test. The latter hang also occurs on an untouchedmainsnapshot.