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

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

[Peet Nick]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

Hey,

I am having the following issue that the buffer gets corrupted when
horizontally resizing the terminal window.

For reference please see this thread:
https://bbs.archlinux.org/viewtopic.php?id=214830

Screenshot:
https://s32.postimg.org/6hws6v39x/Screenshot_from_2016_07_13_23_15_31.png

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?

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

[Bart Schaefer]

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.

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

[Peet Nick]

[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]

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@brasslantern.com>
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.
>

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

[Bart Schaefer]

On Jul 16,  1:41am, Peet Nick wrote:
}
} But even with the stock settings (removed all configuration files) the
} 'problem' is still there.

I'm not sure what you tell you; you tangentially indicated that you are
on archlinux, and I see from some poking around that the zsh package
for that distribution includes an /etc/zsh/zprofile -- perhaps something
from there is influencing?

You also haven't said whether you're making the window larger or smaller
(or wider but shorter, etc.) when this happens.

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

[Peet Nick]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

Sorry, let me explain again.

I did the following to reproduce this behavior (On Arch Linux and Ubuntu
16.04):

(1) Installed Zsh (Arch Linux: Git; Ubuntu: zsh 5.1.1)
(2) Removed every local configuration file and checked if files (/etc/zsh/)
are empty:
      /etc/zsh/{zshrc,zlogin,zlogout,zprofile,zshenv}
      ~/.zshrc
(3) Open a terminal with zsh as shell & "cat /proc/cpuinfo"
(3) Horizontally resize the terminal window to the minimum and slowly
resize it back to the normal size
(4) Repeat (3) until you see that the content of the cpuinfo get deleted or
overwritten by some text


On Sat, Jul 16, 2016 at 5:49 AM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Jul 16,  1:41am, Peet Nick wrote:
> }
> } But even with the stock settings (removed all configuration files) the
> } 'problem' is still there.
>
> I'm not sure what you tell you; you tangentially indicated that you are
> on archlinux, and I see from some poking around that the zsh package
> for that distribution includes an /etc/zsh/zprofile -- perhaps something
> from there is influencing?
>
> You also haven't said whether you're making the window larger or smaller
> (or wider but shorter, etc.) when this happens.
>
>

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

[Bart Schaefer]

On Jul 16,  3:31pm, Peet Nick wrote:
}
} (3) Horizontally resize the terminal window to the minimum and slowly
} resize it back to the normal size
} (4) Repeat (3) until you see that the content of the cpuinfo get deleted or
} overwritten by some text

I don't have a 16.x handy.  I can't reproduce that on Ubuntu 12.04.  The
entire content will scroll up several lines the first time I shrink it,
but on subsequent resizes it stays the same.

Somebody else will have to look at this, but I think it's (new?) behavior
of the terminal rather than of zsh.