gum filter --height: list viewport shrinks cumulatively on every window-resize event

Summary

When gum filter is run with a fixed --height, every tea.WindowSizeMsg re-subtracts the header, help view, and padding from the viewport height without ever recomputing a fresh base. Resizing the terminal window therefore causes the list viewport to shrink step-by-step until it collapses. This is a static-analysis finding based on the current main branch; I did not execute the program.

Location

• File: filter/filter.go
• Function: model.Update, case tea.WindowSizeMsg: (approx. lines 288-301 on main, Aug 2026)

case tea.WindowSizeMsg:
    if m.height == 0 || m.height > msg.Height {
        m.viewport.SetHeight(msg.Height - lipgloss.Height(m.textinput.View()))
    }
    // Include the header in the height calculation.
    if m.header != "" {
        m.viewport.SetHeight(m.viewport.Height() - lipgloss.Height(m.headerStyle.Render(m.header)))
    }
    // Include the help in the total height calculation.
    if m.showHelp {
        m.viewport.SetHeight(m.viewport.Height() - lipgloss.Height(m.helpView()))
    }
    m.viewport.SetHeight(m.viewport.Height() - m.padding[0] - m.padding[2])

Problem

The base height is only reset when m.height == 0 || m.height > msg.Height. With a fixed --height N (where N <= terminal height), that condition is false, so the reset never happens. However, the three subsequent adjustments (header, help, padding[0]+padding[2]) run unconditionally on every WindowSizeMsg. Since WindowSizeMsg is delivered once at startup and again on every terminal resize, the subtractions are applied cumulatively to an already-reduced value instead of being recomputed from N.

A secondary imbalance in the same handler: in auto-height mode (m.height == 0) the text input's height is subtracted from the viewport, but in fixed-height mode it never is, so the composed view (textinput + viewport + padding) exceeds the requested --height by the input line even before resizing.

Trigger / Reproduction

Based on source analysis (not executed):

1. Run gum filter --height 12 (with or without --header, default --show-help adds the help view) with enough options piped in.
2. Resize the terminal window several times.
3. Each resize event subtracts header/help/padding again from the already-shrunk viewport height.

Expected Behavior

The layout should be a pure function of the current window size and configuration flags: with a fixed --height N, the viewport should occupy a stable portion of N regardless of how many resize events occur.

Actual Behavior

Viewport height decreases by headerHeight + helpHeight + verticalPadding on every WindowSizeMsg, eventually reaching zero/negative values, collapsing or misrendering the list.

Impact

Any scripted use of gum filter --height (a documented flag) degrades visually after the user resizes their terminal, which is common in tiling window managers and during initial terminal setup. Repeated resizes make the picker unusable.

Suggested Direction

Recompute the viewport height absolutely on each WindowSizeMsg rather than applying deltas, e.g. derive viewportHeight = min(m.height, msg.Height) - inputHeight - headerHeight - helpHeight - verticalPadding in one place. In fixed-height mode, account for the text input line the same way auto-height mode does.

Evidence

• m.height is only assigned from o.Height at model construction (filter/command.go, Run()), so for --height N > 0 the reset guard stays false whenever the window is at least N rows tall.
• SetHeight calls are relative (m.viewport.Height() - delta), and no state marks that the adjustments were already applied for the current event.
• tea.WindowSizeMsg is delivered repeatedly by Bubble Tea on SIGWINCH, so the handler is re-entered many times during a session.