Long input hints overflow horizontally (e.g. field-value hints on insert) #12

New Issue

2026-05-28T14:45:02+01:00

oliversturm commented

2026-05-28 14:45:02 +01:00

(Migrated from github.com)

Observed

A hint that doesn't fit on the available width simply runs off to the right. Field-value hints on insert (simple mode) trigger this readily.

Design call needed

Several options, not mutually exclusive:

Wrap to multi-line. Reserve a hint area that can be 1–N rows; expand when needed; reclaim the space when the hint is short.
Hard length cap. Truncate with an ellipsis and surface the full hint on demand (e.g. press a key to expand).
Dynamic-resize hint pane. Same as 1, but with explicit min/max bounds and a smooth resize.
Shorter hint content. Trim the source hint strings to the shortest useful form; combine with one of the above.

Pedagogy-vs-screen-space tradeoff: hints help learners, but truncating the most useful bit defeats the purpose. Wrapping (option 1 or 3) is probably the right default; a length cap is a backstop, not a primary mechanism.

### Observed A hint that doesn't fit on the available width simply runs off to the right. Field-value hints on `insert` (simple mode) trigger this readily. ### Design call needed Several options, not mutually exclusive: 1. **Wrap to multi-line.** Reserve a hint area that can be 1–N rows; expand when needed; reclaim the space when the hint is short. 2. **Hard length cap.** Truncate with an ellipsis and surface the full hint on demand (e.g. press a key to expand). 3. **Dynamic-resize hint pane.** Same as 1, but with explicit min/max bounds and a smooth resize. 4. **Shorter hint content.** Trim the source hint strings to the shortest useful form; combine with one of the above. Pedagogy-vs-screen-space tradeoff: hints help learners, but truncating the most useful bit defeats the purpose. Wrapping (option 1 or 3) is probably the right default; a length cap is a backstop, not a primary mechanism.

oliversturm commented

2026-05-30 10:06:00 +01:00

(Migrated from github.com)

Fixed in f7ca288.

Root cause: the Hint panel was a fixed one content row. Long prose hints (field-value hints on insert, the parse.usage.* synopses) wrapped but everything past the first line was clipped, hiding the most useful tail. The candidate-list path was already safe — it scrolls horizontally with </> markers.

Fix (ADR-0022 Amendment 5):

Dynamic height: the hint body is pre-wrapped and the panel is sized to the line count — one row by default, growing to a 3-row cap, and reclaiming the space when the hint is short or empty. The candidate list still scrolls on one row.
Ellipsis backstop: if a hint needs more than 3 rows, the last visible row ends with … so overflow is signalled rather than silently dropped. (Verified: the worst-case 299-char synopsis → 3 rows + ellipsis at 80 cols, full 3 rows at 160 cols.)
Shortened the standout offender: parse.usage.sql_create_table was a 299-char synopsis (~4× the next longest). It is now a terse one-liner; the full column- and table-level grammar remains in help.ddl.sql_create_table (reachable via help). The long insert.form_b_* notes render in the scrollable Output panel, not the Hint panel, so they were left as-is.

Covered by long_prose_hint_shows_tail_across_multiple_rows, short_hint_keeps_panel_at_one_content_row (reclaim), long_hint_grows_panel_but_caps_at_max_rows, clamp_wrapped_truncates_with_ellipsis_past_max, plus six re-baselined full-screen snapshots.

Fixed in f7ca288. Root cause: the Hint panel was a fixed one content row. Long **prose** hints (field-value hints on `insert`, the `parse.usage.*` synopses) wrapped but everything past the first line was clipped, hiding the most useful tail. The candidate-list path was already safe — it scrolls horizontally with `<`/`>` markers. Fix (ADR-0022 Amendment 5): - **Dynamic height:** the hint body is pre-wrapped and the panel is sized to the line count — one row by default, growing to a 3-row cap, and reclaiming the space when the hint is short or empty. The candidate list still scrolls on one row. - **Ellipsis backstop:** if a hint needs more than 3 rows, the last visible row ends with `…` so overflow is signalled rather than silently dropped. (Verified: the worst-case 299-char synopsis → 3 rows + ellipsis at 80 cols, full 3 rows at 160 cols.) - **Shortened the standout offender:** `parse.usage.sql_create_table` was a 299-char synopsis (~4× the next longest). It is now a terse one-liner; the full column- and table-level grammar remains in `help.ddl.sql_create_table` (reachable via `help`). The long `insert.form_b_*` notes render in the scrollable Output panel, not the Hint panel, so they were left as-is. Covered by `long_prose_hint_shows_tail_across_multiple_rows`, `short_hint_keeps_panel_at_one_content_row` (reclaim), `long_hint_grows_panel_but_caps_at_max_rows`, `clamp_wrapped_truncates_with_ellipsis_past_max`, plus six re-baselined full-screen snapshots.

oli referenced this issue from a commit

2026-06-10 19:14:29 +01:00

fix(ui): geometry-fixed hint-panel height kills the typing jump (#20, ADR-0046 DA1/DA2)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oli/rdbms-playground#12

Long input hints overflow horizontally (e.g. field-value hints on insert) #12

Observed

Design call needed

Long input hints overflow horizontally (e.g. field-value hints on `insert`) #12