From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2797 invoked by alias); 16 Jan 2018 19:32:35 -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: List-Unsubscribe: X-Seq: 42290 Received: (qmail 27229 invoked by uid 1010); 16 Jan 2018 19:32:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf0-f45.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.215.45):SA:0(-1.9/5.0):. Processed in 2.682769 secs); 16 Jan 2018 19:32:35 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d270wkL9tVJOt3jWgkpZi/RH1yMUQGITSCwmUNsWIPs=; b=PzRqGix3ZHjmShhweJBtJqpJMk+bfAqINBGzOxhDxl72/4QcsyRM3tx6f45ygeuuoH pBnouo1+b3q7tVKzV4aFwZX/7TRzXUXH3dtd2qBG7AzYA4T4Ra406L8vjKmesw+Y1Kp6 oMUsU8k+nFzX70LxX3e2AJLlSHZrYoIaBnZILDpZV4pr1GNR08e0zi+UWFeZIFA1j2zT bFk2u1fvk/LrPqc0/hYw2s71m7ubpqVU4lJ+kLHhRtkxONYwXK7JER6bMALhKyYza1cx 37LQ6sD69h2BydPNTFZ54hIdKHFMY+voVYyfPquEGVFfdtAwWq8NhU6rjySvuF2jIt9l bmrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d270wkL9tVJOt3jWgkpZi/RH1yMUQGITSCwmUNsWIPs=; b=M0oFn0Qg2B97Vnldy6eKvgv+tBqHsvnEHVlP96qvC3HidM0h68ToNq0F0Wnwr/P/AG t2wC7Vb4F0HuOT+jV9YeBjtV9CJOYMZTQ2EI5kFcvpBYIQ/HThP8YGIFTlPatbKL9p5x MsRrceEbKD+SWCyI3STe5kS2lM0EePpEvd5Qch1FqxB3xlr3uOLcHYle6Iewp+lGXtCe KCVMiA1YQ0499FTPUgAB2wSiR52Z5CEWE63brLnOLf9VSONuxw+CHCREWJp/0s0od/l8 ++fruwzNHCoo5CdUME5ZYHpIc8lZFwE5eX8lihavBXZyorIV06hwvREMxzJocNHb8ptf MjhA== X-Gm-Message-State: AKwxytfvzH5q46i7pFWU/j3sYrvkoRhF+dfqVYt+/Cku11oe4GdJo587 PVMNneszyP+zQgT9X+nb2sDVakQSVaA0KigN0Jz6ow== X-Google-Smtp-Source: ACJfBot90tzVKNi13ufjBPL13bIOxKsdXqbnHuxnTd7rTMT1ph7mIlTKNLfNE54DznvqO4L2UjmyYBDSaYBaU823Ngw= X-Received: by 10.25.148.1 with SMTP id w1mr2045806lfd.32.1516131147913; Tue, 16 Jan 2018 11:32:27 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20180115103558.1258-1-warepire.ml@gmail.com> <20180115103558.1258-2-warepire.ml@gmail.com> From: Bart Schaefer Date: Tue, 16 Jan 2018 11:32:27 -0800 Message-ID: Subject: Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt. To: Warepire - Cc: "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" On Tue, Jan 16, 2018 at 9:04 AM, Warepire - wrote: > > I don't think doing this based on ZLE_RPROMT_INDENT is the way to go, libvte > based terminals require the number of TCUPs to match the number of lines the > final prompt will have when drawn. I am open for fixing this patch, if we > can reach an agreement on what the proper handling should be. The situation is and pretty much always has been intolerable. Some terminals linefeed as soon as the rightmost column is filled, and most but not all of those swallow a newline if it is the next character sent. Some feed when anything, even a zero-width character or control sequence, is sent when there is something in the rightmost column; others do so only when the next character sent is printable. Others behave in one of these ways only for the bottomost-rightmost position. Some have a "bug compatibility mode" which means you don't know whether they're going to do this lunacy or not. And the available terminfo bits don't adequately describe all the combinations, especially in the "bug compatibility" case. One of the reasons zsh introduced the "prompt truncation" escapes is so that the user can control whether his prompt ever reaches the rightmost column, because there's no way for the C code to get this right in all cases. So whether we keep this change or one like it depends in part on which behavior we think is now most common, because somebody is going to have to do a workaround in their prompt settings no matter what we do.