fix(zsh): prompt is not re-rendered on terminal resize, so baked right-side padding wraps

[lemtoc]

As of v0.3.0 (c73dc6c).

Summary

Line 1 right-alignment is implemented by baking spaces into PROMPT (lower_first_line pads to exactly columns, src/render/mod.rs:168). The string is rendered once per precmd with the COLUMNS value of that moment. When the terminal shrinks afterwards (pane split, window resize), zsh redisplays the same static string into a narrower terminal and the line wraps mid-segment:

… koutei/readOnly
 (ap-northeast-1)                                   22:16:
39

(observed after splitting a pane; the aws segment and the clock tear across three lines). The prompt only recovers at the next precmd.

Cause

src/shell/init.zsh registers preexec/precmd/zshexit/line-init hooks only — there is no TRAPWINCH. zsh updates COLUMNS and redisplays the prompt on SIGWINCH, but redisplay re-expands the existing PROMPT string; the padding computed for the old width is baked in. Any prompt that right-aligns via padding (rather than RPROMPT, which zsh reflows natively but only supports on the final line) must re-render on resize — powerlevel10k and starship both do this.

Proposed fix

• Add a TRAPWINCH handler that re-sends a render request with the fresh COLUMNS and applies the reply via the existing zle -F update path (_nova_drain_and_redraw + zle reset-prompt). All plumbing already exists; the handler is a few lines.
• Preserve any user-defined TRAPWINCH (call the previous definition if present), and guard against non-ZLE contexts the way _nova_register_update_handler already does.
• Debounce is likely unnecessary (interactive resizes generate few WINCHes and the worker render is cheap), but coalescing by generation counter already happens on the apply side (_nova_last_applied_gen).
• Regression coverage belongs to the interactive harness (test(zsh): add an interactive zsh E2E harness (zpty) #24): resize the pty and assert the prompt re-renders without wrapping.

Notes

• The fitting-priority issue (fix(render): dir segment is sacrificed first under narrow widths — fitting priority is inverted #32) determines what the narrow prompt shows; this issue ensures the narrow prompt is rendered at all without waiting for the next command. They are independent fixes in different layers.

---

🤖 Generated with Claude Code — Claude Fable 5

[lemtoc]

Investigated on fix/44-resize-redraw. Summary: the proposed TRAPWINCH re-render was implemented and works in isolation, but it is the wrong approach — and the issue's premise about prior art turned out to be incorrect. Recording the findings here and deferring the full fix.

What happened with the proposed fix

Re-rendering with the fresh COLUMNS on SIGWINCH works in a bare pty. In real terminals, three things happen concurrently on a pane split / window resize:

1. the terminal (cmux/Ghostty) reflows the existing screen content to the new width;
2. zsh redisplays the multiline PROMPT itself (ZLE performs a reset-prompt on WINCH);
3. any additional redraw Nova issues cannot reliably erase the old rows — after reflow, zsh's notion of where the prompt started is invalidated, so each extra redraw can leave another stale copy behind and the artifacts amplify under continuous drag-resize.

Even with Nova's redraw fully disabled, step 2 alone produces transient duplication — that is a pre-existing zsh/terminal limitation, present on main, not something introduced by this branch.

Correction: neither powerlevel10k nor starship re-renders on WINCH

The issue body claims "powerlevel10k and starship both do this". Verified against their sources — neither has a TRAPWINCH (or any WINCH handling) at all:

• powerlevel10k solves it differently: the right-alignment gap is computed at prompt-expansion time, not baked at precmd time. See internal/p10k.zsh:6466 (gap=$((COLUMNS - left_len - _p9k__ret - ZLE_RPROMPT_INDENT))) and the _p9k__clm snapshot trick around :8376-8379, which saves the real COLUMNS during expansion (and temporarily sets COLUMNS=1024 to defeat zsh's own prompt-line truncation). Since zsh re-expands PROMPT on WINCH anyway, the gap comes out right for the new width with zero extra redraws — which is exactly why it doesn't amplify.
• starship's src/init/starship.zsh has no WINCH handling either; the right side is plain RPROMPT (repositioned natively by ZLE), and its fill module has the same stale-baked-padding problem we do.

So "re-render on WINCH" is a road no major prompt actually took, and the amplification above is presumably why.

The real fix: move the gap from bake time to expansion time

Translate the p10k approach to Nova's architecture: the worker returns line-1 left/right as pre-rendered strings plus their visible widths, and the shell-side PROMPT embeds the gap as an expansion with the combined width W baked in as a numeric literal:

LEFT${(l:$(( COLUMNS > W ? COLUMNS - W : 0 )):: :)}RIGHT

This satisfies every constraint at once: terminal-independent, keeps the multiline PROMPT (no preprompt-ification, async updates keep working), updates immediately on resize by riding zsh's built-in WINCH re-expansion, and adds no redraws beyond what zsh already does — so no duplication beyond the pre-existing baseline.

Why it's out of scope for a P2: it requires setopt prompt_subst, which turns every piece of dynamic content the worker emits (branch names, paths, env-derived strings) into a command-injection surface unless a strict escaping layer is added for $, backticks, etc. on top of the existing % escaping. That is a prompt-rendering redesign, not a spot fix. Known degradation: fitting decisions (which segments to drop/truncate) are made in Rust at render time and stay stale until the next precmd; on shrink the gap collapses to 0 and the line wraps cleanly between left and right instead of tearing mid-segment — acceptable.

Mitigation worth landing now

Two small pieces from this branch stand on their own:

• LINE_RIGHT_INDENT = 1 — stop padding line 1 to exactly COLUMNS; leave a one-column right margin. This matches zsh's own ZLE_RPROMPT_INDENT default of 1, and full-width prompt lines are a known zsh hazard (p10k carries a repro and workaround for a zsh bug in exactly this case, internal/p10k.zsh:7195-7196). Reduces tearing on reflow and redisplay.
• E2E regression guard — assert that a pty resize triggers no extra Nova prompt (zsh's own redisplay only), does not advance the render generation, and does not clobber a user-defined TRAPWINCH. This pins down "Nova does no harm on resize" as the intended contract until the expansion-time-gap redesign happens.

Disposition

• Keep this issue open, deferred; the fix belongs to a prompt-rendering redesign (expansion-time gap + escaping layer).
• Separately worth filing: emit OSC 133 semantic prompt markers. Cheap, ignored by non-supporting terminals, and terminals like kitty use the marks to reposition/redraw prompts correctly across resizes themselves — the only true fix for the reflow-duplication baseline, but it is terminal cooperation, not something zsh-side code can force.

---

🤖 Generated with Claude Code — Claude Fable 5