From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11666 invoked by alias); 15 Jul 2016 23:50:04 -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: 38860 Received: (qmail 29677 invoked from network); 15 Jul 2016 23:50:04 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f41.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.213.41):SA:0(0.3/5.0):. Processed in 0.320847 secs); 15 Jul 2016 23:50:04 -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.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: peetnick2@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.41 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=irIG8x7jgu9zk7anS+Uya44Rj2SbQk+H59VbJS8Ipog=; b=FwjF70Wu7roP/MYoENapk+cfJXHk2yY0kYj0YNwBniTUhQI6DDCWrxflFbtYbMIWIb b68lhX1yfOXWeBw10npHxJIktIBVrq/L8fcLVm2Yba4raCl9vOogJcmcQZ5DJwnpk8AW fjq9t4OEj65/zztXLd+aAPDai67FThOFNBWz7hcs1kt7L0xZ/QQhUBMpJmp70ppFSY4S ehY3U/rB3kW7uhbNink6fop0xEE4zemSjMX6yputneCZn4QgWyYZe6BFAnyKRvyW01sV pXrt8vqpR8xKXChGZehOSXinO1hkaDsBCAbrpZ/5eDFnokh2r/3wxQoqv9NbK1Q6tFWE v3dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=irIG8x7jgu9zk7anS+Uya44Rj2SbQk+H59VbJS8Ipog=; b=bcUnRhpJM+5e0yXf6rcujKKiKgawK1pWTwSsH6CFRvvc8Tnny4jO5pWze1X4EFQclT vQKqntixDcoOXnELqy/N1wvS50UbII/L/un41QLAsoAcV8apfdxyXCS50XbKC76TOf/e ePOQAmYAw53jd/HFtDyoejHPp11yvpNZlVnFeoN8daGXTpBNNWd0+ozc2zjNO4zUT5KA y1XcLY10qBvVj8eZ1nRLcInP0A5TbGm25IiKcOsZ2l9JJGnFKpbbeFWulNcM8ARZyugR 3BqAPDZnCWjjexDAjn0Q6gzFBKGkEu6PfDLM9W5qZvuGTpzDbmn2G4h9xrfmmBt5ZEFB p9vA== X-Gm-Message-State: ALyK8tKayq6PqzMP4roeTYelYImmZ3pc5yoverU8PfQ/xDj8ToSYUHnIIvWkGX0IBvWvxtO214ZLp0PI1M4bkA== X-Received: by 10.159.37.137 with SMTP id 9mr11903682uaf.53.1468626108165; Fri, 15 Jul 2016 16:41:48 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <160715120957.ZM32565@torch.brasslantern.com> References: <160715120957.ZM32565@torch.brasslantern.com> From: Peet Nick Date: Sat, 16 Jul 2016 01:41:47 +0200 Message-ID: Subject: Re: [BUG/IMPROVEMENT] Buffer corruption while horizontally resizing terminal window To: Bart Schaefer Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary=001a113d0aa07c33730537b52992 --001a113d0aa07c33730537b52992 Content-Type: text/plain; charset=UTF-8 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 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. > --001a113d0aa07c33730537b52992--