Prompt redrawing issues with wrapped prompt on SIGWINCH

Prompt redrawing issues with wrapped prompt on SIGWINCH

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am seeing weird redrawing issues when resizing the terminal window with the prompt at the bottom, and the prompt needs to be rewrapped.

TEST CASE:

1. zsh -f
2. setopt promptsubst
3. PS1="\${(pl:\$((\$COLUMNS))::=:)} %# "

Now fill the terminal window, e.g. with "ls", so that the prompt gets displayed at the bottom.

When resizing the terminal window now, Zsh does not redraw itself properly: the prompt will moves upwards, overwriting output from "ls".

This also happens with a static PS1, when the window gets too narrow:

PS1="===================================== %# "


There is no clear pattern in what goes wrong. With my prompt it will also duplicate the first part of it, and it seems to make a difference if the first line is "full" before the linebreak.

1. Start:
⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[🐍 ?]
❯❯

2. Make it smaller:
⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[🐍 ?]
❯❯ 

3. Larger again (original size):
⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[🐍 ?]
❯❯

4. Smaller again:
⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[~]⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[🐍 ?]
❯❯


My terminal is rxvt-unicode, but this also happens with gnome-terminal.

I am using the awesome window manager, using a tiled layout and use mod-j/k to resize the window.

Using TRAPWINCH shows a single WINCH signal per resize.

In case this isn't reproducible for you I'd like to get some pointers how to debug this.
It's probably related to zsh's SIGWINCH handling?


Thanks,
Daniel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVMY+ffAK/hT/mPgARAvAuAJ4sEL1XxztaAqQd4Xn+NYdzky+7eACbBAyh
6rKH3Tlc1ZkQ2CZ/TsOAx2s=
=Jjm4
-----END PGP SIGNATURE-----

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

[Mikael Magnusson]

On Sat, Apr 18, 2015 at 12:56 AM, Daniel Hahler
<genml+zsh-workers@thequod.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I am seeing weird redrawing issues when resizing the terminal window with the prompt at the bottom, and the prompt needs to be rewrapped.
>
> TEST CASE:
>
> 1. zsh -f
> 2. setopt promptsubst
> 3. PS1="\${(pl:\$((\$COLUMNS))::=:)} %# "
>
> Now fill the terminal window, e.g. with "ls", so that the prompt gets displayed at the bottom.
>
> When resizing the terminal window now, Zsh does not redraw itself properly: the prompt will moves upwards, overwriting output from "ls".
>
> This also happens with a static PS1, when the window gets too narrow:
>
> PS1="===================================== %# "
>
>
> There is no clear pattern in what goes wrong. With my prompt it will also duplicate the first part of it, and it seems to make a difference if the first line is "full" before the linebreak.

Urxvt reflows long lines on resize and obviously this happens before
zsh gets a chance to redraw the prompt. I don't know if there's any
possible way zle can know how the cursor moved because of this, and
especially difficult is to know how much the display scrolled.

-- 
Mikael Magnusson

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

[Bart Schaefer]

On Apr 18,  5:43am, Mikael Magnusson wrote:
}
} On Sat, Apr 18, 2015 at 12:56 AM, Daniel Hahler
} <genml+zsh-workers@thequod.de> wrote:
} > -----BEGIN PGP SIGNED MESSAGE-----
} > Hash: SHA1
} >
} > I am seeing weird redrawing issues when resizing the terminal window with the prompt at the bottom, and the prompt needs to be rewrapped.
} >
} 
} Urxvt reflows long lines on resize and obviously this happens before
} zsh gets a chance to redraw the prompt. I don't know if there's any
} possible way zle can know how the cursor moved because of this, and
} especially difficult is to know how much the display scrolled.

In fact you can see what's happening if you change your test case like
so:

PS1='${(pl:COLUMNS::=:)} %# %{$(sleep 5)%}'

(I removed some unnecessary expansions and changed quoting to get rid of
backslashes.)  The above makes zsh pause for 5 seconds in the middle of
drawing the prompt.  This will allow you to see what urxvt has done with
the display and the cursor position before zsh gets a chance to begin to
redraw the prompt.

On my system the cursor ends up near the left end of the first line of
"======" (directly above where it was previously, the "======" having
wrapped to two lines) when urxvt is done narrowing the window.  The
prompt redraw expects it to be at the end of the second line near the
"%" sign, so it moves up one line before beginning to redraw.

Conversely when widening the window, ZLE expects the (previously full)
line of "=====" to have scrolled the terminal down one line because an
"=" was printed in the lower right corner, so it again moves up before
displaying the prompt.  (Unlike the misplaced cursor, this may be a
situation that could be fixed by comparing the previous and new values
of $COLUMNS before deciding how many lines the prompt occupies.)

You can avoid both of those problems by defining the prompt this way:

PS1='${(pl:COLUMNS-1::=:)}
 %# '

That is, leave one blank column at the right and insert an explicit
newline instead of relying on urxvt to wrap at the margin. The newline
forces urxvt to put the cursor on the correct line when narrowing, and
the shortened line of "======" allows zsh to ignore auto-margin-wrap
and therefore correctly compute the number of lines the prompt uses
when widening.

This can be written on one line with $'...' syntax:

PS1=$'${(pl:COLUMNS-1::=:)}\n %# '

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your explanations!

Some remarks: it does not only affect urxvt, but also gnome-terminal. So it's likely to
be a common issue with all terminals?!

Could this be addressed by e.g. having the terminal notify zsh about SIGWINCH before reflowing/rewrapping the text, or something similar?


> PS1=$'${(pl:COLUMNS-1::=:)}\n %# '

This suggested workaround only helps if you resize the window by one column, e.g.
when using the mouse. But modkey-h/l in awesome changes the master-window-factor
by a percent of the screen size.

I had this workaround before already, without knowing why it worked (under some
conditions).  Now at least that is clearer! :)


Thanks,
Daniel.

On 18.04.2015 17:57, Bart Schaefer wrote:
> On Apr 18,  5:43am, Mikael Magnusson wrote:
> }
> } On Sat, Apr 18, 2015 at 12:56 AM, Daniel Hahler wrote:
> } >
> } > I am seeing weird redrawing issues when resizing the terminal window with the prompt at the bottom, and the prompt needs to be rewrapped.
> } >
> } 
> } Urxvt reflows long lines on resize and obviously this happens before
> } zsh gets a chance to redraw the prompt. I don't know if there's any
> } possible way zle can know how the cursor moved because of this, and
> } especially difficult is to know how much the display scrolled.
> 
> In fact you can see what's happening if you change your test case like
> so:
> 
> PS1='${(pl:COLUMNS::=:)} %# %{$(sleep 5)%}'
> 
> (I removed some unnecessary expansions and changed quoting to get rid of
> backslashes.)  The above makes zsh pause for 5 seconds in the middle of
> drawing the prompt.  This will allow you to see what urxvt has done with
> the display and the cursor position before zsh gets a chance to begin to
> redraw the prompt.
> 
> On my system the cursor ends up near the left end of the first line of
> "======" (directly above where it was previously, the "======" having
> wrapped to two lines) when urxvt is done narrowing the window.  The
> prompt redraw expects it to be at the end of the second line near the
> "%" sign, so it moves up one line before beginning to redraw.
> 
> Conversely when widening the window, ZLE expects the (previously full)
> line of "=====" to have scrolled the terminal down one line because an
> "=" was printed in the lower right corner, so it again moves up before
> displaying the prompt.  (Unlike the misplaced cursor, this may be a
> situation that could be fixed by comparing the previous and new values
> of $COLUMNS before deciding how many lines the prompt occupies.)
> 
> You can avoid both of those problems by defining the prompt this way:
> 
> PS1='${(pl:COLUMNS-1::=:)}
>  %# '
> 
> That is, leave one blank column at the right and insert an explicit
> newline instead of relying on urxvt to wrap at the margin. The newline
> forces urxvt to put the cursor on the correct line when narrowing, and
> the shortened line of "======" allows zsh to ignore auto-margin-wrap
> and therefore correctly compute the number of lines the prompt uses
> when widening.
> 
> This can be written on one line with $'...' syntax:
> 
> PS1=$'${(pl:COLUMNS-1::=:)}\n %# '
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVMo6NfAK/hT/mPgARAljnAJ9jrcw/700cwDRKvzQA/HOqa8Cw6gCeKFcb
P2dRi5KptX6iJdLUZjb+aGY=
=bANY
-----END PGP SIGNATURE-----

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

[Bart Schaefer]

On Apr 18,  7:04pm, Daniel Hahler wrote:
}
} Some remarks: it does not only affect urxvt, but also gnome-terminal.
} So it's likely to be a common issue with all terminals?!

Doesn't happen to me with xterm, but it sends multiple SIGWINCH rather
than wait for the final size of the window.

} Could this be addressed by e.g. having the terminal notify zsh about
} SIGWINCH before reflowing/rewrapping the text, or something similar?

Signals are asynchronous at the OS level so the emulator can't control
whether the shell has as chance to respond to the signal before it
redraws the text.  In any case this would require reprogramming the
emulator, so is out of our hands.

} > PS1=$'${(pl:COLUMNS-1::=:)}\n %# '
} 
} This suggested workaround only helps if you resize the window by one
} column, e.g. when using the mouse. But modkey-h/l in awesome changes
} the master-window-factor by a percent of the screen size.

The suggested workaround was successful for me when using mouse-drag to
resize the window, despite urxvt sending only a single SIGWINCH when the
mouse was released, which should be analogous to having the window manager
trigger a proportional resize.  What version of zsh do you have?

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

[Daniel Hahler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18.04.2015 19:21, Bart Schaefer wrote:
> On Apr 18,  7:04pm, Daniel Hahler wrote:
> }
> } Some remarks: it does not only affect urxvt, but also gnome-terminal.
> } So it's likely to be a common issue with all terminals?!
> 
> Doesn't happen to me with xterm, but it sends multiple SIGWINCH rather
> than wait for the final size of the window.

In xterm I only see a single SIGWINCH (via TRAPWINCH).

> } Could this be addressed by e.g. having the terminal notify zsh about
> } SIGWINCH before reflowing/rewrapping the text, or something similar?
> 
> Signals are asynchronous at the OS level so the emulator can't control
> whether the shell has as chance to respond to the signal before it
> redraws the text.  In any case this would require reprogramming the
> emulator, so is out of our hands.

Yes, the emulator would have to be patched/fixed for this.

Could it emit/forward the signal, and only redraw after it has been
processed by the shell?
Or would the shell have to answer / re-emit the signal for this to work?


> } > PS1=$'${(pl:COLUMNS-1::=:)}\n %# '
> } 
> } This suggested workaround only helps if you resize the window by one
> } column, e.g. when using the mouse. But modkey-h/l in awesome changes
> } the master-window-factor by a percent of the screen size.
> 
> The suggested workaround was successful for me when using mouse-drag to
> resize the window, despite urxvt sending only a single SIGWINCH when the
> mouse was released, which should be analogous to having the window manager
> trigger a proportional resize.  What version of zsh do you have?

I am using zsh from git master, 5.0.7-dev-1 (@2e48eceb).


Thanks,
Daniel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFVMszhfAK/hT/mPgARAhhXAKDNNFviAOKb7FJ4DVmquU0nKMi37QCg0NXP
PjFBV8Q7gcgE+mplIyCVLRY=
=XoS9
-----END PGP SIGNATURE-----

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

[Bart Schaefer]

On Apr 18, 11:30pm, Daniel Hahler wrote:
}
} > Doesn't happen to me with xterm, but it sends multiple SIGWINCH rather
} > than wait for the final size of the window.
} 
} In xterm I only see a single SIGWINCH (via TRAPWINCH).

Must be window-manager dependent, then.

} > } SIGWINCH before reflowing/rewrapping the text, or something similar?
} 
} Could it emit/forward the signal, and only redraw after it has been
} processed by the shell?
} Or would the shell have to answer / re-emit the signal for this to work?

The shell and the emulator would have to deliberately synchronize
somehow, yes.  Since the shell generally doesn't have any connection
to the emulator (only to the pseudo-terminal device they share), this
would not be straightforward.

} I am using zsh from git master, 5.0.7-dev-1 (@2e48eceb).

Hm.  I don't have any explanation, then.