From: Peet Nick <peetnick2@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window
Date: Sat, 16 Jul 2016 01:41:47 +0200 [thread overview]
Message-ID: <CAJwqTS9BrFVa-v90mh7pPzcnx1P-7CvjP5q5fxUc4m3ws6EjAA@mail.gmail.com> (raw)
In-Reply-To: <160715120957.ZM32565@torch.brasslantern.com>
[-- 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.
>
next prev parent reply other threads:[~2016-07-15 23:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-15 14:40 Peet Nick
2016-07-15 19:09 ` Bart Schaefer
2016-07-15 23:41 ` Peet Nick [this message]
2016-07-16 3:49 ` Bart Schaefer
2016-07-16 13:31 ` Peet Nick
2016-07-17 18:29 ` 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=CAJwqTS9BrFVa-v90mh7pPzcnx1P-7CvjP5q5fxUc4m3ws6EjAA@mail.gmail.com \
--to=peetnick2@gmail.com \
--cc=schaefer@brasslantern.com \
--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).