fix(fuzzylist): clamp pickers to the pane with a scrolling viewport#41
Open
todie wants to merge 1 commit into
Open
fix(fuzzylist): clamp pickers to the pane with a scrolling viewport#41todie wants to merge 1 commit into
todie wants to merge 1 commit into
Conversation
Both pickers render every row unconditionally, so a list taller than the pane (e.g. 60+ project files) overflows the alt-screen: rows past the pane height are cut off, the detail bar and footer scroll away, and the cursor can walk out of view. Long rows also soft-wrap, breaking the list's line accounting for mouse clicks. Give fuzzyList a viewport: setViewport(rows, width) caps how many body lines view() emits, a scroll offset follows the cursor in both directions (ensureVisible), and every emitted line is ANSI-aware truncated to the pane width so nothing soft-wraps. rowIndexAt maps clicks through the scroll offset, so click-to-open keeps working while scrolled. The projects browser and both quick-actions stages feed their pane size through on WindowSizeMsg (and when the select-stage option list is created), each reserving its own fixed chrome lines. With no viewport set, behavior is unchanged (unbounded, as before).
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
1 participant
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.
Problem
Both pickers render every list row unconditionally. With more entries than the pane has rows (I hit this with ~66 project files), the alt-screen view overflows: rows past the pane height are truncated, the detail bar and footer disappear, and arrowing down walks the cursor out of view. Independently, rows longer than the pane soft-wrap, which breaks the line accounting
rowIndexAtrelies on for mouse clicks.Fix
Give
fuzzyLista viewport:setViewport(rows, width)caps how many body linesview()emits; a scroll offset (lineOffset) follows the cursor in both directions viaensureVisible(), so the highlighted row is always on screen.x/ansi.Truncate, already an indirect dep) to the pane width so nothing soft-wraps.rowIndexAtmaps clicks through the scroll offset, so click-to-open keeps working while scrolled and clicks on the query block or below the window stay no-ops.WindowSizeMsg(and when the select-stage option list is created), each reserving its own fixed chrome lines.With no viewport set the component behaves exactly as before (unbounded), so existing tests pass unchanged; two new tests cover window-follows-cursor (both directions + click mapping through the offset) and width truncation.
Verified
Drove
projects-uiwith 66 project files in a 25x90 pty and checked the emulated screen: the list windows to the pane with the detail box and footer pinned and visible, scrolling 30 rows down keeps the cursor and its detail preview on screen, and filtering re-clamps the window. Same check onquick-actions-uiat 12x70.