mirror/nanobot
1
0
Fork 0
mirror of https://github.com/HKUDS/nanobot.git synced 2026-08-04 08:28:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

style: trim CSI-u shortcut comments

Browse Source 
Maintainer edit: simplify the explanatory comments for the CSI-u shortcut while preserving the existing behavior and regression coverage.
This commit is contained in:
chengyongru 2026-07-10 11:02:43 +08:00 committed by Xubin Ren
parent 99e04c2da2
commit 45a6466c2c
2 changed files with 4 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
nanobot/cli/commands.py
View File

@ -310,28 +310,12 @@ def _build_cli_key_bindings() -> KeyBindings:
* Enter -> submit the current input (keeps the familiar * Enter -> submit the current input (keeps the familiar
single-line Enter-to-send feel even though the buffer single-line Enter-to-send feel even though the buffer
is multiline-capable). is multiline-capable).
* Alt+Enter -> insert a newline for multi-line input. Universally * Alt+Enter -> insert a newline for multi-line input.
supported, so this is the reliable multiline shortcut.
* Shift+Enter -> insert a newline on terminals that emit the CSI-u * Shift+Enter -> insert a newline on terminals that emit the CSI-u
(kitty / fixterms) keyboard-protocol encoding for it. (kitty / fixterms) keyboard-protocol encoding for it.
""" """
# Terminals speaking the CSI-u (kitty / fixterms) keyboard protocol -- e.g. # prompt_toolkit does not recognize CSI-u, so register its Shift+Enter
# kitty, Ghostty and WezTerm when it is enabled -- send Shift+Enter as the # sequence as a best-effort addition without overriding existing mappings.
# escape sequence "\x1b[13;2u". prompt_toolkit 3.0 has no support for that
# protocol (no way to negotiate it, no default mapping for the sequence), so
# when such a terminal sends it the Vt100Parser fails to recognise the
# sequence and dumps the raw bytes ("^[[13;2u") straight into the buffer.
#
# Register the sequence so it parses as one keypress bound to insert a
# newline instead. "\x1b[13;2u" is absent from prompt_toolkit's default
# ANSI_SEQUENCES table, so this is a pure addition -- setdefault() overrides
# nothing -- carried on Keys.ControlF3, an enum member prompt_toolkit
# declares but never wires to a default sequence or binding.
#
# This is best-effort: without protocol negotiation we can only *react* to a
# CSI-u sequence a terminal already emits, not *request* one. Terminals that
# collapse Shift+Enter into a plain Enter are indistinguishable and fall back
# to Alt+Enter, which is why Alt+Enter stays the primary shortcut.
with suppress(Exception): with suppress(Exception):
from prompt_toolkit.input import ansi_escape_sequences as _aes from prompt_toolkit.input import ansi_escape_sequences as _aes

7
tests/cli/test_cli_input.py
View File

@ -129,12 +129,7 @@ async def test_alt_enter_inserts_newline_on_lf_terminals():
@pytest.mark.asyncio @pytest.mark.asyncio
async def test_csi_u_shift_enter_inserts_newline_not_raw_escape(): async def test_csi_u_shift_enter_inserts_newline_not_raw_escape():
"""Terminals speaking the CSI-u (kitty / fixterms) keyboard protocol send """CSI-u Shift+Enter inserts a newline instead of raw escape bytes."""
Shift+Enter as "\\x1b[13;2u". prompt_toolkit has no support for that protocol
and would otherwise dump the raw escape bytes ("^[[13;2u") into the buffer;
the binding must instead parse it as one keypress and insert a newline. Only
a real PromptSession/parser exercises the ANSI_SEQUENCES registration.
"""
from prompt_toolkit.application import create_app_session from prompt_toolkit.application import create_app_session
from prompt_toolkit.input import create_pipe_input from prompt_toolkit.input import create_pipe_input
from prompt_toolkit.output import DummyOutput from prompt_toolkit.output import DummyOutput