Route unclaimed popup keys back to the prompt - #1011
Conversation
|
Verification: targeted TUI suites green (134 pass, 0 fail across slash-popup-gate, mention-popup, mention-filter, overlays, overlay-key-routing, focus-routing, shell, keybindings). Full gate |
Critic review · no blockersDoes what the Outcome claims: unclaimed printables with an overlay open land in the prompt via prompt insertText plus sentHistoryOnEdit, overlay stays open, permissions/operator gates keep modal handling. Placement is right — the fallthrough sits after every claim (slash/mention/answer/filter/action/nav/Enter), so claimed keys, Enter accept, and Esc dismiss are structurally untouched. Guard (isPrintableInsertKey: single char, no modifiers, >= space) provably excludes Return and Esc sequences, so those paths cannot reach the new code. Verified, not vibes: on the branch worktree at 46c4546, src/tui/overlay-key-routing.test.ts 3/3 pass, plus throwaway probes (since removed) confirmed a permissions gate swallows x (prompt stays empty, gate stays open) and help + x routes to the prompt with the overlay open. Worktree left clean, no commits. Should-fix (non-blocking)
Notes |
|
Critic nits addressed in 976871c (tests only, routing unchanged):
Verification: targeted TUI suites (overlay-key-routing, slash-popup-gate, mention-popup, prompt-box, focus-routing) 76 pass 0 fail; |
Summary
With a suggestion popup open, keystrokes the popup does not use were silently dropped instead of reaching the prompt, so filter text could vanish without feedback. Unclaimed printable keys now fall through to the prompt buffer while the overlay stays open; permission and operator gates keep their modal key handling.
Verification
Fixes CL-6723
DO NOT MERGE