fix(tui): scroll transcript when composer has text (#1677)#1715
Closed
tdccccc wants to merge 1 commit into
Closed
Conversation
When `composer_arrows_scroll` is enabled, Up/Down always scroll the transcript regardless of whether the composer has text. Previously arrows only scrolled when the composer was empty. With text in the composer, mouse wheel events (sent as arrow keys by terminals without mouse capture) navigated input history instead, making it impossible to review earlier conversation while mid-typing. Fixes Hmbown#1677
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the TUI composer's arrow key logic so that enabling composer_arrows_scroll triggers transcript scrolling even when the composer is not empty. This adjustment prevents terminals that map mouse-wheel events to arrow keys from unintentionally navigating input history during active typing. The test suite has been updated to verify this new behavior and confirm that history navigation remains functional when the scroll option is disabled. I have no feedback to provide.
This was referenced May 17, 2026
Owner
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
2 participants
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.
Summary
composer_arrows_scrollis enabled, Up/Down keys now always scroll the transcript, regardless of whether the composer has text.Problem
On terminals without mouse capture (e.g. Warp on Windows, legacy conhost), mouse wheel events are converted to Up/Down arrow keys by the terminal. When
composer_arrows_scroll = true, these arrow keys only triggered transcript scrolling when the composer was empty. If the user had text in the input field, the arrow keys navigated input history instead, preventing scrolling while typing.Users had to manually add
mouse_capture = trueto their config to work around this, which isn't obvious.Fix
Removed the
app.input.trim().is_empty()guard inhandle_composer_history_arrow. Whencomposer_arrows_scrollis enabled, arrows always scroll the transcript. When disabled (the default on non-Windows with mouse capture), behavior is unchanged.Test plan
history_arrow_handles_nonempty_inputto explicitly setcomposer_arrows_scroll = falsecomposer_arrows_scroll_nonempty_still_navigates_history→composer_arrows_scroll_nonempty_also_scrollsto verify new behavior