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

Aperta
  • Qualcosa non va?
#2,125 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript
Ambito
cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
JavaScript
Stelle
11
Fork
0
Merge medio
2h 55m
PR unite (30g)
294

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di hyparam/hypaware

Tutte le issue di hyparam/hypaware

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.