* [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window @ 2016-07-15 14:40 Peet Nick 2016-07-15 19:09 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Peet Nick @ 2016-07-15 14:40 UTC (permalink / raw) To: zsh-workers [-- 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window 2016-07-15 14:40 [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window Peet Nick @ 2016-07-15 19:09 ` Bart Schaefer 2016-07-15 23:41 ` Peet Nick 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 2016-07-15 19:09 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window 2016-07-15 19:09 ` Bart Schaefer @ 2016-07-15 23:41 ` Peet Nick 2016-07-16 3:49 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Peet Nick @ 2016-07-15 23:41 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers [-- 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. > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window 2016-07-15 23:41 ` Peet Nick @ 2016-07-16 3:49 ` Bart Schaefer 2016-07-16 13:31 ` Peet Nick 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 2016-07-16 3:49 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window 2016-07-16 3:49 ` Bart Schaefer @ 2016-07-16 13:31 ` Peet Nick 2016-07-17 18:29 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Peet Nick @ 2016-07-16 13:31 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers [-- 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. > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window 2016-07-16 13:31 ` Peet Nick @ 2016-07-17 18:29 ` Bart Schaefer 0 siblings, 0 replies; 6+ messages in thread From: Bart Schaefer @ 2016-07-17 18:29 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-17 18:48 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-15 14:40 [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window Peet Nick 2016-07-15 19:09 ` Bart Schaefer 2016-07-15 23:41 ` Peet Nick 2016-07-16 3:49 ` Bart Schaefer 2016-07-16 13:31 ` Peet Nick 2016-07-17 18:29 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).