test(tui): cover C-x C-x literal passthrough to the focused session#619
Merged
Conversation
…trator `C-x C-x` is the escape hatch that cancels the C-x chord prefix and forwards a literal C-x (0x18) to the focused session, so harnesses that bind C-x internally (grok, bash's `C-x C-e`, vim completion) still receive it. The behavior shipped with the orchestrator-as-session work but had no regression coverage. Add tests for both copies of the escape hatch — the main-view PTY path and the orchestrator/operator panel — asserting the second C-x forwards 0x18 to the focused session and clears the chord prefix, while the first (prefix) C-x forwards nothing on its own.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this is
A regression test for
C-x C-xpassthrough in the TUI.Investigation finding: the behavior already works
The task was to make
C-x C-xcancel the C-x prefix and forward a literalC-x to the focused session (so harnesses like
grokthat bind C-x internallycan still receive it). On investigation, this already works — there is a
dedicated "escape hatch" that does exactly this, in two places:
is_pty_captured()branch ofon_key): when aC-x chord is in flight and the next key is C-x, it clears the chord and
queues
0x18(literal C-x) to the focused session's PTY.handle_orchestrator_key): the sameescape hatch, forwarding
0x18to the orchestrator session.This shipped with the orchestrator-as-session work (commit
5a2ad3c). So theruntime behavior the request describes is not broken — the second C-x does
not get swallowed; it is forwarded.
What was actually missing was test coverage: nothing locked in this
behavior, so a future refactor of the key-dispatch flow could silently break
it (and the byte forwarding is invisible in the mock-daemon test setup unless
you intercept the input channel).
What this PR adds
Two tests, asserting the escape hatch forwards a literal C-x and clears the
prefix, for each copy of the logic:
ctrl_x_ctrl_x_forwards_literal_ctrl_x_to_focused_pty— captured PTY view:first C-x arms the prefix and forwards nothing; second C-x forwards
0x18and clears the chord state + indicator.
orchestrator_panel_ctrl_x_ctrl_x_forwards_literal_ctrl_x— same, inside theoperator panel, asserting the byte targets the orchestrator session.
Both swap the
pty_input_txchannel for one the test owns, so the forwardedbytes are observable.
Scope
Test-only — no production code changes.
cargo buildand the new tests pass.Relevant binary
This PR touches only
crates/cli(test code) → the binary isconstruct. Nobehavior change, so the binary is unchanged from
main.