Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window

[Peet Nick <peetnick2@xxxxxxxxx>]

Thank you for the response.

But even with the stock settings (removed all configuration files) the
'problem' is still there. I accidentally also tried this with bash and it
preserved the content above.

https://s32.postimg.org/gl0ytfzqt/issue.png

I am not sure what I should change here, PS1?


On Fri, Jul 15, 2016 at 9:09 PM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
wrote:

> On Jul 15,  4:40pm, Peet Nick wrote:
> }
> } A user pointed out that it is caused by "zle reset-prompt".
> }
> } Is this intentional behavior that the old buffer gets corrupted when
> } resizing the window?
>
> To say that it's caused by reset-prompt is sweeping a lot of details
> under the rug.  For one thing, the reset-prompt widget isn't really
> involved unless you are explicitly calling it somewhere.
>
> Importantly, zsh/ZLE don't maintain a "buffer" of what the whole screen
> looks like.  The only "buffer" is the contents of the editable command
> line, i.e., the stuff that comes after the prompt.  The prompt itself
> is drawn based on a calculation of the width of each line relative to
> the width of the window, and the number of lines derived from that and
> from any embedded newlines; the rest of the screen contents are unknown,
> and the vertical position (how far above the last line the prompt is
> starting) is based on what ZLE knows about what was previously output
> by e.g. completion (it can't know about output of external commands).
>
> When you resize the window, especially vertically, you change all those
> calculated positions and ZLE has to attempt to move the cursor to a
> reasonable starting place before redrawing everything.  It redoes this
> calculation every time it receives a SIGWINCH signal.  Gnome terminal
> and some others send SIGWINCH for every incremental change, so this is
> happening repeatedly as you resize.  (Other terminals send the signal
> only when you have finished resizing and release the mouse button.)
>
> Whether the result of all this redrawing is "pretty" depends on a lot
> of factors:  whether you've accurately used %{ and %} to delimit any
> non-printing portions of your prompt (an example might be title bar
> control sequences); whether parts of the prompt are ever wider than
> the screen, introducing implicit folding onto more lines; whether an
> RPS1 is also being displayed; how your terminal handles auto-wrapping
> when characters are written into or past the rightmost column; whether
> you have a TRAPWINCH function and if so what it does; and so on.
>
> So, is it intentional behavior?  It's intentional that the redrawing
> is done at all, because a lot of people complained when (years ago)
> zsh just ignored changes in screen size until the next prompt was
> printed e.g. after accept-line.  It's not intentional that redrawing
> can cause the prompt to wander around, but it's not entirely under
> zsh's control whether that happens or not.  You can probably make it
> disappear by adjusting the contents of your PS1, RPS1, and/or
> ZLE_RPROMPT_INDENT variables.
>