TUI multiselect has no viewport, and hyp init's source picker already overflows a 24-row terminal

Open
  • Is something wrong?
#2,125 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript
Domain
cli

Research direction

Start in src/core/cli/tui/render.js at renderMultiselect and compare its rendering with the select viewport added for #2124. Trace how opts.rows reaches the renderer through src/core/cli/walkthrough.js and src/core/cli/wizard/pick.js. Done means a test using the visible bundled picker descriptors at 80 columns and 24 rows confirms the frame uses at most 23 physical rows and keeps both the cursor and Submit row reachable.

Written by the indexing model from the issue text.

Description

Source: #2124 at a39f1c20cf2081c47bc47a857f8a4e720a5daae6 (review deferral)
Location: src/core/cli/tui/render.js (renderMultiselect), src/core/cli/walkthrough.js (tuiPromptFactory), src/core/cli/wizard/pick.js
Severity: minor

Evidence

#2124 gives select a viewport (selectWindow, bounded by RenderOpts.rows). multiselect is left without one, and unlike select its option list is not a short fixed set in the code: the picker table is manifest-sourced from every installed plugin's contributes.picker (LLP 0130 #picker-block), read through loadPickerCatalog(), and each row carries a label plus a multi-line summary.

The bundled catalog alone already overflows a standard terminal. Rendering the real visible descriptor set through the shipped renderer at 80 columns:

multiselect platform=darwin visible=9 columns=80  -> physicalRows=34  (terminal 24)
multiselect platform=darwin visible=9 columns=120 -> physicalRows=29  (terminal 24)
multiselect platform=linux  visible=8 columns=80  -> physicalRows=30  (terminal 24)
multiselect platform=linux  visible=8 columns=120 -> physicalRows=26  (terminal 24)

Driving the shipped multiselect() against a fake 80x24 TTY with those same options shows the failure mechanism from #1816 verbatim:

walkthrough multiselect on an 80x24 TTY: cursor-up sequences written = [30A [30A (terminal is 24 rows)

\x1b[30A on a 24-row terminal clamps at row 1, six rows inside the frame, so every keystroke after the first redraws over the remains. This is the interactive source picker on the hyp init path (wizard/pick.js -> defaultPromptFactory -> tuiPromptFactory -> multiselect, and the legacy walkthrough.js path), so it is more travelled than the hyp report fix picker #1816 was filed against.

Installing further plugins that contribute picker rows makes it strictly worse, and the long summaries (Claude Desktop's is 4 wrapped rows at 80 columns) mean the count of rows is not the count of options.

Expected behavior

A multiselect frame stays inside the terminal the same way a select now does: renderMultiselect honours opts.rows with a window that always contains the cursor (and the Submit row when the cursor is on it), and says what it is hiding.

Why deferral is safe

Pre-existing, not a regression from #2124: render.js had no notion of terminal height at all before that PR, so this path is no worse than it was. #2124 is correct and minimal for the defect it was filed against, and per CLAUDE.md the smaller change lands first. The workaround is a taller terminal or HYP_NO_TUI=1, which routes to the legacy numbered prompt.

Acceptance condition

A test rendering a multiselect built from the visible bundled picker descriptors at { columns: 80, rows: 24 } asserts countPhysicalRows(frame, 80) <= 23, failing against today's renderMultiselect. The Submit row and the cursor row must both stay reachable.

Dominant language
JavaScript
Stars
11
Forks
0
Avg merge
2h 55m
Merged PRs (30d)
294

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from hyparam/hypaware

All issues in hyparam/hypaware

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.