Don't raise the help panel on '?' while editing a queued prompt

[warp-dev-github-integration]

Description

When editing a queued prompt inline in the queued prompts panel with an empty regular input, pressing ? incorrectly raised the agent view shortcuts (help) panel above the input instead of being inserted into the queued prompt being edited.

Root cause: the shift-? → ToggleAgentViewShortcuts FixedBinding on the Input keymap context fires whenever the regular input buffer is empty (EMPTY_INPUT_BUFFER) and agent view is active (ACTIVE_AGENT_VIEW). While a queued prompt is being edited inline, the inline edit editor is a focused descendant of the Input view, so the Input keymap context remains active. With an empty regular input, the shift-? binding matched and swallowed the keystroke — opening the help panel instead of letting the queued-prompt editor handle ? as ordinary text input.

Fix: add the existing QUEUED_PROMPT_INLINE_EDITOR_OPEN_CONTEXT guard to the binding's context predicate. This is the same flag already used to keep up/down arrow keys inside the queued-prompt inline editor (it is set in Input::keymap_context when is_editing_queued_prompt is true). With the guard, the help-panel toggle is suppressed while a queued prompt is being edited, so ? falls through to the inline editor and is inserted like any other character.

The change is one line in app/src/terminal/input.rs: the shift-? FixedBinding context predicate gains & !id!(QUEUED_PROMPT_INLINE_EDITOR_OPEN_CONTEXT), matching the adjacent guards.

Linked Issue

N/A — self-contained bug fix to the queued-prompt inline editor / help-panel keybinding interaction.

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below.

Testing

• I have manually tested my changes locally with ./script/run

This is a keymap-context-predicate change that mirrors an existing, proven guard: the earlier "keep up/down arrow keys inside the queued-prompt inline editor" change added the same QUEUED_PROMPT_INLINE_EDITOR_OPEN_CONTEXT flag to the Up binding's context predicate. The flag is set in Input::keymap_context based on is_editing_queued_prompt, which returns true while a queued row is being edited inline.

Manual verification steps:

1. Enable the queued prompts feature and start an agent view conversation.
2. Queue a prompt, then click the row's edit button to enter inline edit mode (leave the regular input empty).
3. Type ? while focused in the queued-prompt inline editor.
4. Before the fix: the help/shortcuts panel opens above the input and ? is not inserted. After the fix: ? is inserted into the queued prompt being edited and the help panel does not open.
5. Confirm the help panel still toggles on ? when not editing a queued prompt (empty regular input, agent view active).

No new automated test was added: the change is a one-line keymap-context predicate reusing an already-defined constant that is already used identically in the same init function (for the Up binding guard), consistent with how the analogous arrow-key guard was shipped. A full from-scratch build/test run was not feasible in this environment; the change compiles by construction (identical usage to the adjacent guards).

Screenshots / Videos

N/A.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Changelog Entries for Stable

CHANGELOG-BUG-FIX: Typing ? while editing a queued prompt no longer opens the help panel; ? is now inserted into the queued prompt being edited.

Conversation: https://staging.warp.dev/conversation/b972b4bf-df8e-492f-a667-28d16df10a10
Run: https://oz.staging.warp.dev/runs/019f5d5a-2df9-7860-9ed8-5dfbf844ea74

This PR was generated with Oz.