fix: fix terminal key protocol handling #902
Conversation
WalkthroughReworks terminal input and CSI handling across three areas: Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
tscreen.go (1)
304-304: Clarify the comment to match actual behavior.The comment states "if we don't have a TERM" but the code doesn't check the TERM environment variable. On Windows, win32-input-mode is used unconditionally. Consider updating the comment to accurately reflect this behavior.
Apply this diff to clarify the comment:
- // on Windows, if we don't have a TERM, use only win32-input-mode + // on Windows, use only win32-input-mode
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tscreen.go(1 hunks)
🔇 Additional comments (1)
tscreen.go (1)
303-314: Good simplification of the CSI U mode initialization logic.The OS-based branching provides a cleaner approach than the previous WezTerm-specific handling. The separation between Windows (win32-input-mode only) and non-Windows (three-protocol composite) is clear and maintainable.
The logic to force behavior for WezTerm was wrong, and was the result of an incorrect escape sequence for the win32-input-mode. Fixing that lets us eliminate the WezTerm specific logic.
df2ae0e to
393ed0b
Compare
This seems to fix things quite nicely for WezTerm regardless of running remotely or locally on Windows, or on macOS. The goofy nesting level only needs to be done when dealing with nesting, and we can be reasonably sure that all content requiring the extra parse pass comes together and is complete (and is generally only required for non-keyboard data.)
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
_demos/mouse.go (1)
18-21: File comment is inconsistent with updated UI text.The file-level comment at lines 18-20 and the inline comment at line 87-88 still reference "Press ESC twice to exit", but the on-screen instruction now says "Press Ctrl-Q to Quit". Consider updating the comments to mention both options (ESC twice still works, but Ctrl-Q is now the primary method).
input.go (1)
738-749: Redundant check and consider using constructor for nested parser.Two minor observations:
The check at line 746
if P[2] > 0is redundant since line 738 already ensuresP[2] > 0 && P[2] < 0x80.The nested parser is created manually, missing the pre-allocated buffer from
newInputParser(). Consider using the constructor for consistency:if P[0] == 0 && P[1] == 0 && P[2] > 0 && P[2] < 0x80 { // only ASCII in win32-input-mode if ip.nested == nil { - ip.nested = &inputParser{ - evch: ip.evch, - rows: ip.rows, - cols: ip.cols, - } + ip.nested = newInputParser(ip.evch) + ip.nested.rows = ip.rows + ip.nested.cols = ip.cols } - if P[2] > 0 { - ip.nested.ScanUTF8([]byte{byte(P[2])}) - } + ip.nested.ScanUTF8([]byte{byte(P[2])}) return }Regarding the static analysis hint about integer conversion at line 747: this is a false positive since the bounds check at line 738 (
P[2] > 0 && P[2] < 0x80) guarantees the value fits safely in auint8.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
_demos/mouse.go(2 hunks)input.go(6 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
_demos/mouse.go (1)
key.go (2)
Key(332-332)KeyCtrlQ(459-459)
🪛 GitHub Check: CodeQL
input.go
[failure] 747-747: Incorrect conversion between integer types
Incorrect conversion of a signed 32-bit integer from strconv.ParseInt to a lower bit size type uint8 without an upper bound check.
🔇 Additional comments (6)
_demos/mouse.go (1)
199-201: LGTM!The Ctrl-Q quit handling follows the established pattern and correctly uses
s.Fini()beforeos.Exit(0), consistent with the ESC twice exit behavior.input.go (5)
821-823: LGTM!Appending explicit
0for empty CSI parameters ensures proper handling of protocols that distinguish between omitted parameters and zero-valued parameters.
831-836: LGTM!Early return after handling mouse events with the
<prefix prevents incorrect fall-through to other CSI handlers.
851-867: LGTM!The CSI-u (Kitty keyboard protocol) handling is correctly structured. Removing the
hasLTdependency allows proper handling of unambiguous Kitty protocol sequences.
884-898: LGTM!The relaxed
hasLTrequirement for CSI~handling with proper modifier extraction looks correct. The special case forP0 == 27(xterm modifyOtherKeys) correctly handles both control characters and printable runes.
901-910: LGTM!The general CSI key dispatch correctly applies modifiers when present and preserves the aixterm compatibility hack for the
Pkey conflict.
The logic to force behavior for WezTerm was wrong, and was the result of an incorrect escape sequence for the win32-input-mode. Fixing that lets us eliminate the WezTerm specific logic.
This significantly fixes the win32-input-mode, particularly the nesting so that only the sequences requiring the extra parsing pass receive it.
A few other minor bugs are resolved as well.
Summary by CodeRabbit
Refactor
New Features
Bug Fixes
✏️ Tip: You can customize this high-level summary in your review settings.