Repository navigation
fix(tui): show a scroll rail on a settings choice list that doesn't fit - #7024
Conversation
Opening a setting's choices in /settings shows as many options as fit and scrolls to keep the selected one in view, but nothing on screen says the list goes on. Language has 17 options; at 80x24 the list ends at "11. de", at 60x16 at "5. zh-Hant", and there is no hint the other languages exist until you arrow past the last row. Theme is the same. The settings list behind it already paints render_panel_scroll_rail for this, so use it here too, on the rows the options occupy. It is painted after the paragraph, because the paragraph restyles its whole area, and the labels give up one column only when the rail is drawn, so a long label can't run under it. A list that fits draws no rail and renders as before. The 80x24 edit-theme golden gains the rail on its option rows; the 120x32 one fits all 17 themes and does not change. Signed-off-by: Lstarsky0 <59827030+Lstarsky0@users.noreply.github.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
github-actions
Bot
added
the
contribution-gate
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e46387acc8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Rect { | ||
| x: inner.x, | ||
| y: inner.y.saturating_add(lines.len() as u16), | ||
| width: inner.width, |
There was a problem hiding this comment.
When choices overflow (for example, Theme at 80×24), this new rail occupies inner.right() - 1, but each entry in last_choice_hitboxes still uses the full inner.width. handle_mouse therefore treats the rail cell as the underlying choice: moving the pointer across rail rows changes the selection and live-previews those themes, while clicking the paint-only cue selects an option. Reserve the rail column from the recorded choice hitboxes, as the settings list already does.
AGENTS.md reference: crates/tui/AGENTS.md:L22-L24
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
🤖 Claude Opus 5.5, working for the maintainer.
Confirmed and fixed on main in 3352da9. When the rail is drawn, the choice hitboxes now give up its column, so hovering or clicking the rail no longer selects or live-previews a choice. The hover, live-preview and click paths all hit-test through rect.contains. I merged before reading this review; that was my miss, not @Lstarsky0's.
Thanks, @Lstarsky0. The red Lint run here was not yours. CI tests a PR merged with current I also checked the rail placement. The body paragraph does not wrap, and it starts at
|
#7023 (/mcp status line says "No matches" during an empty search) merged as 7553ba1; #7024 (scroll rail on /settings choice lists that don't fit) merged after its branch was updated past the clippy fix in 37a596b. Both changelogs get the same entries. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NBKbhx19BRbZtvWK8rVKjz
Both PRs merged with an unread Codex review finding. I merged them without reading the review thread; these are the follow-ups. #7022 (/statusline height, P2): the picker budgeted one footer row (rows + 7), but render_modal_footer wraps the action hints. In German at 80x24 the 60-column inner width wraps "Space umschalten … Enter speichern / Esc abbrechen" onto two rows, so Git branch was still hidden until you scrolled. The picker now builds its hints once, measures them with action_footer_lines at the popup's inner width (the width centered_modal_area will give it, minus border and padding) and budgets rows + 6 + footer rows. The hints array is reused by render_modal_footer. #7024 (settings choice rail, P2): the rail paints the last column of the choice rows, but each choice hitbox still spanned the full inner width, so hovering or clicking the paint-only rail selected (and live-previewed) the choice on that row. Hitboxes now give up that column when the rail is drawn, matching the label width. The third finding (#7012, P1: the /statusline mode hint shown in English) was already fixed: StatusItem::hint(locale) routes through MessageId::StatusPickerModeHint. Verified in a real TUI at 80x24 with an isolated HOME (CW/artifacts/approval-card-20261018/run-statusline-{de,en}.sh): - German, before (codewhale-after6): the list ends at "[ ] Workspace", footer on two rows - German, after: "[ ] Git branch" shown above the two footer rows - English, after: all 11 items and the one-row footer, as before The rail-hitbox change was checked by reading handle_mouse's use of last_choice_hitboxes; no mouse event was driven. Checks: - cargo test -p codewhale-tui --lib -- views:: config_view edit_theme settings status_picker statusline: 528 passed; 0 failed; 1 ignored - cargo clippy -p codewhale-tui --all-targets --all-features --locked with CI's flags: clean; cargo fmt --check: clean Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NBKbhx19BRbZtvWK8rVKjz
What and why
When a setting's choices don't fit, /settings shows as many as it can and scrolls to keep the selected one in view, but nothing says the list goes on. Language has 17 options. At 60×16, Language, before:
After:
At 80×24 the list stops at
11. dewith the same lack of a cue, and Theme behaves the same way.The settings list behind this view already uses
render_panel_scroll_railfor exactly this, so the choice list now does too, over the rows the options take. Two details: the rail is painted after the paragraph, because the paragraph restyles its whole area, and labels give up one column only when the rail is drawn, so a long label can't run under it. A list that fits draws no rail and is unchanged. Like the settings list's rail, it's paint-only.edit_theme_80x24.txtgains the rail in the last column of its eleven option rows and nothing else;edit_theme_120x32.txtfits all 17 themes and is unchanged.Issue
No-Issue: settings choice lists give no cue that more options are below, no issue filed for it
How I tested it
edit_theme_matches_goldens_at_blocker_sizeswithCODEWHALE_BLESS_GOLDENS=1; the test passes against the existing 120×32 golden.cargo fmt --all -- --check,cargo clippy -p codewhale-tui --all-targets --all-featureswith CI's flags, andcargo check -p codewhale-tui --all-targets: clean. Clippy also on 1.99, pluscargo +1.89.0 check -p codewhale-tui.cargo nextest run -p codewhale-tui --lib: 15349 passed, none failed.Checklist
maincargo fmt --allpasses, and tests cover new or changed behaviordocs/features.toml(cargo test -p codewhale-tui --test feature_registrychecks it) — n/a