feat: Support kitty and win32-input-mode protocols (fixes #30) #34
Conversation
This adds support for advanced key reporting modes, borrowed from tcell. This also includes the X term modifyOtherKeys protocol. Note that win32-input-mode is not tested yet as we don't fully support Windows (no termio implementation for it yet), but that will change soon.
|
Caution Review failedThe pull request is closed. WalkthroughAdded two public string fields to Vt for CSI‑U/WezTerm sequences, set them based on TERM/TERM_PROGRAM/Windows detection, and emit the enable sequence at screen start and the disable sequence at screen stop. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
source/dcell/ttyscreen.d (1)
188-207: Env/legacy handling for advanced key protocols looks soundThe conditional init around Lines 188–207 plus the legacy gating at Lines 208–218 is coherent:
- On Windows, when
TERMis empty orTERM_PROGRAM == "WezTerm", you restrict to win32-input-mode only, which matches the comment about not mixing modes.- On non-Windows WezTerm, you switch to pure CSI-U (
>1u/<u), avoiding modifyOtherKeys/win32, as per the “WezTerm is unhappy if we ask for other modes” note.- Legacy terminals zero out
vt.enableCsiU/vt.disableCsiUalong with other OSC/DSC features, so old/quirky terms never see these sequences.This wiring aligns with the existing
legacymodel and keeps advanced modes opt-out on problematic terminals.If you want to trim repetition, you could cache
auto termProgram = environment.get("TERM_PROGRAM");once before theversion (Windows)block and reuse it, but that’s purely cosmetic.Also applies to: 208-218
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
source/dcell/ttyscreen.d(5 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: gdamore
Repo: gdamore/dcell PR: 27
File: source/dcell/ttyscreen.d:164-171
Timestamp: 2025-12-08T19:16:26.974Z
Learning: VT series terminals (vt100, vt102, vt220, vt320, vt420) are strictly monochrome. There are no color terminals with names like "vt220-color" in the VT series. The vt525 is mythical and would use "ansi" for $TERM if needed. Therefore, checking term.startsWith("vt") for monochrome classification is correct.
Learnt from: gdamore
Repo: gdamore/dcell PR: 27
File: source/dcell/ttyscreen.d:763-766
Timestamp: 2025-12-08T19:10:45.974Z
Learning: In source/dcell/ttyscreen.d, the newTtyScreen() factory function intentionally does not accept a term parameter because the TtyScreen constructor handles environment variable resolution internally with an optional term parameter. Users needing to override the terminal type should call the constructor directly: new TtyScreen(newDevTty(), "custom-term").
📚 Learning: 2025-12-08T19:10:45.974Z
Learnt from: gdamore
Repo: gdamore/dcell PR: 27
File: source/dcell/ttyscreen.d:763-766
Timestamp: 2025-12-08T19:10:45.974Z
Learning: In source/dcell/ttyscreen.d, the newTtyScreen() factory function intentionally does not accept a term parameter because the TtyScreen constructor handles environment variable resolution internally with an optional term parameter. Users needing to override the terminal type should call the constructor directly: new TtyScreen(newDevTty(), "custom-term").
Applied to files:
source/dcell/ttyscreen.d
📚 Learning: 2025-12-08T19:17:33.657Z
Learnt from: gdamore
Repo: gdamore/dcell PR: 27
File: source/dcell/ttyscreen.d:448-494
Timestamp: 2025-12-08T19:17:33.657Z
Learning: In source/dcell/ttyscreen.d, Color.reset is defined as a value above the range of valid colors. In the sendColors() function, after emitting the reset sequence (vt.resetFgBg), Color.reset values naturally skip all subsequent color-setting logic (isRGB checks and palette range checks < 8, < 256) because they are out of range, which is the correct behavior by design.
Applied to files:
source/dcell/ttyscreen.d
📚 Learning: 2025-12-08T19:16:26.974Z
Learnt from: gdamore
Repo: gdamore/dcell PR: 27
File: source/dcell/ttyscreen.d:164-171
Timestamp: 2025-12-08T19:16:26.974Z
Learning: VT series terminals (vt100, vt102, vt220, vt320, vt420) are strictly monochrome. There are no color terminals with names like "vt220-color" in the VT series. The vt525 is mythical and would use "ansi" for $TERM if needed. Therefore, checking term.startsWith("vt") for monochrome classification is correct.
Applied to files:
source/dcell/ttyscreen.d
🔇 Additional comments (1)
source/dcell/ttyscreen.d (1)
235-235: Start/stop lifecycle for CSI-U modes is symmetric and minimalHooking
vt.enableCsiUintostart()(Line 235) andvt.disableCsiUintostop()(Line 274) keeps the advanced keyboard protocols active only while the screen is running and restores the previous state on teardown. With legacy/empty cases already mapped to"", this is a safe, no-op-on-unsupported-terms change.Also applies to: 274-274
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This adds support for advanced key reporting modes, borrowed from tcell. This also includes the X term modifyOtherKeys protocol.
Note that win32-input-mode is not tested yet as we don't fully support Windows (no termio implementation for it yet), but that will change soon.
Summary by CodeRabbit
Improvements
Bug Fixes
✏️ Tip: You can customize this high-level summary in your review settings.