wavetermdev
[Bug]: Terminal incorrectly render command line when command is longer than the widget width
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
- Open a terminal widget
- 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
https://github.com/user-attachments/assets/82d2410e-8f5c-47cc-962b-091f72be7fc0
scenario of the bug
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).
same problem for me, i solved it by explicitly setting "editor:wordwrapbool": true in config/waveterm/setttngs.json
