Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Prompt redrawing issues with wrapped prompt on SIGWINCH

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).

Version: GnuPG v2.0.22 (GNU/Linux)


Messages sorted by: Reverse Date, Date, Thread, Author