zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Hahler <genml+zsh-workers@thequod.de>
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: Re: Prompt redrawing issues with wrapped prompt on SIGWINCH
Date: Sat, 18 Apr 2015 19:04:13 +0200	[thread overview]
Message-ID: <55328E8D.8000502@thequod.de> (raw)
In-Reply-To: <150418085735.ZM12718@torch.brasslantern.com>

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


  reply	other threads:[~2015-04-18 17:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-17 22:56 Daniel Hahler
2015-04-18  3:43 ` Mikael Magnusson
2015-04-18 15:57   ` Bart Schaefer
2015-04-18 17:04     ` Daniel Hahler [this message]
2015-04-18 17:21       ` Bart Schaefer
2015-04-18 21:30         ` Daniel Hahler
2015-04-18 23:00           ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55328E8D.8000502@thequod.de \
    --to=genml+zsh-workers@thequod.de \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).