[Bug]: Terminal incorrectly render command line when command is longer than the widget width

[nicholaslck]

Current Behavior

The input will suddenly being masked and the PS1 prompt will gone (e.g. path to home "~" is gone )

Expected Behavior

The input line should not be overwrite and keep allowing user to type in the next line.

Steps To Reproduce

1. Open a terminal widget
2. Keep typing "a" until the line is longer than the widget window width

Wave Version

v0.11.0

Platform

macOS

OS Version/Distribution

Sequoia 15.3

Architecture

arm64

Anything else?

I am using zsh with zap-zsh/zap-prompt

Questionnaire

• I'm interested in fixing this myself but don't know where to start
• I would like to fix and I have a solution
• I don't have time to fix this right now, but maybe later

[nicholaslck]

Screen.Recording.2025-02-04.at.10.55.06.AM.mov

scenario of the bug

[sawka]

I tested locally and I'm not seeing this behavior, but I can think of a couple reasons why things might not be working:

• we might have an off-by-one bug somewhere at certain sizes? (i don't think it is this)
• your prompt might be reporting its size wrong (zap-prompt)? this can happen if certain escape sequences aren't correctly wrapped (https://tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html) and for zsh https://zsh.sourceforge.io/Doc/Release/Prompt-Expansion.html#Visual-effects (the %{} section)
• the size isn't getting sent correctly to the terminal SIGWINCH isn't firing correctly (or there is an out of order update).

if you make the terminal a bit smaller (so it is easy to count). can you run stty size which will show [rows] [cols]. and then re-do your test and we can count the number of columns that actually appear on the screen. we should be able to see if they match up?

i have a pending PR to fix the "out of order" window size updates (although i haven't actually seen this problem come up in the real world).