From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25660 invoked by alias); 15 Jul 2016 19:09:39 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 38859 Received: (qmail 314 invoked from network); 15 Jul 2016 19:09:38 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f193.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.192.193):SA:0(0.0/5.0):. Processed in 0.519705 secs); 15 Jul 2016 19:09:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=FFacM0yZ8OtIHxFjdX0vqyC+JphNRG/2mOXsHEE0MS0=; b=w4lShkdb3tnP/TWHl3dWp9aE1019+ZV2D+B1JHUaNn0/5HdWinB1z5PP3sfiWjBviR qVckO8d7/55Fnawu/Xe2Nt+eQHzUmVWLfVvCcb12q4r6R/t6C+R9jTdR3Sj3zoXxz/US gwTFnPKDs1EUfH8BvLojtoyGjzEpWbsPkZqncfvkZycs/VM2TQpbZgFKleAURjPlxYcQ g//hTDgIQLadufRheg3DSYzjHG+e39FtBl2GzSq4In1ZkgM8qgqOCJkvDIkOwJBKHca+ mfVJhIyrYLVBPHGSFBG491vpvmJvYU15HWsxXipx/TVr5cvmwQ9Y1zGeceza/+jG5Mms M+wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=FFacM0yZ8OtIHxFjdX0vqyC+JphNRG/2mOXsHEE0MS0=; b=lLBSTmnk9cCaSiyl3O/RCE/uU+VGC9kwVOcQHad00TWmALemRDCeQx/ALa13DWcJn2 Hfj7m/CydRgh7v2t5gAHszraRae6dkKkHfk4j94i09N2zE9A9crbeq+jZuEeLfvOCKO/ 1EoCvoN8gU+ovCe8W7jaqARUN5z5QFk4nHhDsqjEzL42rrAWHobQfk+0CAwFNQmVPjoS FzT4R1zkj9wyNqkFg2BULXzFp3KT+8HCk0raovC73tjAhcnra76baLeaCBqtnqfd5z5G JRnIRjIT5PcOxciDV2CO+HykhWEeTmzCur6lSRTC4kYRJtl9s/ZM1DrwuCRXZ++BBih+ 4YCw== X-Gm-Message-State: ALyK8tKrNyvdkBOfNw5O6vH5+vd0Y7F51xbjxU4jox3NRL0CiXVYY0l6Z1teDo8jVx5XDw== X-Received: by 10.98.108.5 with SMTP id h5mr24221254pfc.22.1468609770574; Fri, 15 Jul 2016 12:09:30 -0700 (PDT) From: Bart Schaefer Message-Id: <160715120957.ZM32565@torch.brasslantern.com> Date: Fri, 15 Jul 2016 12:09:57 -0700 In-Reply-To: Comments: In reply to Peet Nick "[BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window" (Jul 15, 4:40pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.