From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15194 invoked by alias); 3 Nov 2016 03:30:30 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22077 Received: (qmail 13577 invoked from network); 3 Nov 2016 03:30:29 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua0-f178.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.217.178):SA:0(0.0/5.0):. Processed in 0.861442 secs); 03 Nov 2016 03:30:29 -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=SPF_PASS,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: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.217.178 as permitted sender) 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=pgKh7yX1Q7YZs+NEQb50Z1Wn/vTo1p9qAsgAqLLozt0=; b=Kj/0qGJnVhMZc8kyEqpEW9hB88S+PStX7WnpM1WfQHOAj432ZjpH1vQgJbwXetH4Xf +ZuAuyXd63D/HiV62k90f3feZS7aUmUQkIE+qIWTpitOF/Fe/8nh/ocpzgFDLKGAAr28 z6bri+WZvkRyGtRTUT2KLspcwbpRYQCL616sxring03Pp9zWjyyRO3Kzzw8sXNs6/Ng2 Jhrax3YI8EzpCMED66GvjUeXLjGKTE/XBLVGm69nkMX3ckPCIPWZtNKaotj4R7LooNov P9ZYLnD+BV3zeUSmB2QxMBC1VxRp4GrUYmqHQavvoqaXO0e/4Q8+a/Tjjkr74W0sAlyS KZFw== 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=pgKh7yX1Q7YZs+NEQb50Z1Wn/vTo1p9qAsgAqLLozt0=; b=YvXrt6J2ur1iqpzHa7ZHeclIPkpXTBp/slR/mxFFIXR6W55i7bP5+F35T6fbcA0Uvm jrKXz8mUZsLwsv9zQUnDeZL7kgo7QlCL5Dc19PC/0DaTqKil6PLpxMZMLVtbTklYU4zP SAzT6tZMmNz77Blf2nzgzxHpDT6BUJ3Kwu/bjzhZTVElTiJPFHMhgiWwiIWDrSZ54qLE J6L20mMWWBACGBIWsa0jaz8dvCOWGDq48jEUbVYsDHtEA6Mni72i9EvG+IKVtDqOn+Ck UIo41//FlsXoiNRWzdlj/5hccTyAlR4uoVsKiRu6E1wXv1KHz/zvIF5HmexBR0fgdj4k rLOA== X-Gm-Message-State: ABUngvc6He7PCw2cM3u5BHeRkMLn8pIEE7+OaKcS9PfsfeU5T2uODgyaWKniw5oWq7izNA== X-Received: by 10.159.48.28 with SMTP id h28mr5692178uab.39.1478143824158; Wed, 02 Nov 2016 20:30:24 -0700 (PDT) From: Bart Schaefer Message-Id: <161102203050.ZM1616@torch.brasslantern.com> Date: Wed, 2 Nov 2016 20:30:50 -0700 In-Reply-To: Comments: In reply to "Aaron U'Ren" "Re: Long Prompt Lines Cause Terminal History Loss on Window Resize" (Nov 1, 10:53pm) References: <161101204434.ZM26466@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Long Prompt Lines Cause Terminal History Loss on Window Resize MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 1, 10:53pm, Aaron U'Ren wrote: } } Interesting. So is there no way to mitigate this issue in zsh? Because bash } doesn't produce the same results in either tmux or xfce terminal. That's because bash doesn't redraw the prompt when the terminal size changes. Zsh handles the WINCH signal and updates the prompt to keep the right-side prompt in the right place, etc. This was a widely requested behavior a few years ago when window managers with features like live drag and transparent terminals became popular. The terminal-specific behavior is what happens when the last line is both redrawn and is long enough to wrap, in those circumstances, not how the scrollback is handled when nothing changes. There's also some other stuff going on -- e.g., depending on how the prompt is defined, zsh may try to keep track of how many lines the prompt occupies and to reposition the cursor appropriately before beginning to print it. You can also get different behavior with different window/session managers; those with the "live drag" feature send a continuous flood of WINCH signals in hopes that the terminal can refresh in real time as the size changes, whereas others wait for the drag operation to end and then send a single WINCH. So a terminal that works as you expect on one desktop may "fail" on another. } Also, if this is purely a terminal implementation problem, can you } give me any direction about where the problem lies so that I can file } a more accurate bug report with the project? The difficulty is that it's not just one project / one bug, it's the interaction of three or more applications each of which has different presentation goals. } And what terminals do you recommend } that exhibit correct behavior on resize? Not something I keep track of, sorry. If I had to guess, I would say there probably isn't one that everyone would agree is always "correct". } Is tmux affected because it is } also flawed or because the terminal that contains it is flawed? More likely the latter, but possibly both. I don't use tmux. One thing you could try is to prefix your prompt with "%-2<<". This means to always leave 2 or more spaces before the right edge of the screen, truncating the prompt on the left if it doesn't fit on one line. (This only works on the last line of a prompt that has any embedded newlines.) Thus the prompt will disappear when the terminal gets very small, which might keep everything else where you want it.