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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.