From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27311 invoked by alias); 16 Jan 2018 20:23:50 -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: 42291 Received: (qmail 8580 invoked by uid 1010); 16 Jan 2018 20:23:50 -0000 X-Qmail-Scanner-Diagnostics: from mail-it0-f48.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.214.48):SA:0(-1.9/5.0):. Processed in 6.70556 secs); 16 Jan 2018 20:23:50 -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,FREEMAIL_FROM, HTML_MESSAGE,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: warepire.ml@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VX44RWO6hsBqt+fz4eUD5TZ19IKSdsUCUxIawYuNtdM=; b=JAwsxlNlHkGMcq+0tH3VMfSx7SKtGW2CNipvoLOsDJq7KFo0zOU89Ii4/Mde5MqnEk aXY+SdcesZdC8L3zEU1VkXy5XYN/vpdR/pbnbOInxqj4qXFn5RoZESnhvUdF0JSgLJpM xXnF5WrfcrJcf4j7KKOTKbFbnGpsS1FGikFsbAxtKnx9+lHSVMqGT2B5GiqFPa72g74k arCnr6bCGuOsCRPLD6mPcp+Lf9Mj/5wXFQWSglNV5ZQledbeshMKggy4lngZKEUJ3LZ6 ZZ3SKmWd7Wizwzy69lyPVLuFrnxbLj2YAwDjMrRKLw8YRoym+l8D6JkMIcqB0cZhEr/9 15hQ== 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=VX44RWO6hsBqt+fz4eUD5TZ19IKSdsUCUxIawYuNtdM=; b=MSACvcdEeLLy83ReAEJ9vpo2uiOuspl7DjYQ+vo9OAohQ3zHAgQso6UZftbef0YE4t ayIPsWmc3ZraSyRCrUhe5P5gruPi01tu7CJx0tvfEGrvRh6xkv6NvLkuatz6x3LVZ0Tl k3vA7clGSob8U9H0PRkRCfDLUuprXn7EzgOLjELmFWwb+Ts82qgBU11nJpTSztXNV6bO WiEVNwSqFs1YTLiDM4muRvxqJz9okQKMl2vZLxTemoMrUYr0J9e1r9ZsCro8t9H2JVTZ fXW5FLBbqt+PLc12qM939bNtPJi4h/4Sj2U7wvcnhQ4VKxXwfUaAV2N8W2d1FO0awI64 X0cA== X-Gm-Message-State: AKwxytfNT3IpvvipoW1CmOpuydANRSTgDBnOQnSJ5vu6Y4rxWyl0zCBe yKUw6Zz1brKBSoqzm1zcpaDnew87xJ+vgkJ0Ng== X-Google-Smtp-Source: ACJfBouAtouNlXNuBPeODB4kb3rLom6NnKqo8wwZRUgwLRl8T5arhc/qUcPP8seFPF2HmdleZsdE91MkbFhvnomh6Vk= X-Received: by 10.36.112.206 with SMTP id f197mr6242872itc.133.1516134220155; Tue, 16 Jan 2018 12:23:40 -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: Warepire - Date: Tue, 16 Jan 2018 21:23:39 +0100 Message-ID: Subject: Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt. To: Bart Schaefer Cc: "zsh-workers@zsh.org" Content-Type: multipart/alternative; boundary="001a113f76b89fcf4a0562ea81b0" --001a113f76b89fcf4a0562ea81b0 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 16, 2018 at 8:32 PM, Bart Schaefer wrote: > 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. > I might have worded myself badly, if so, I apologize. What I meant with proper handling was how to properly introduce a configuration setting for this and determine it's default numerical value (or boolean?), since my patch in it's current state may trigger the problems zsh wants to avoid (at least in theory). Checking through the terminfo and termcap manuals, with my poor understanding there doesn't seem to be a (combination of) termcap(s) to detect this safely enough to attempt it. I have no idea what it should be called, but I am leaning on a default as 1, turning the check into "> zterm_columns - offset", and just like ZLE_RPROMPT_INDENT users can set it to 0 if their terminal supports it (and fixes the erased-output problem without freak-out). As the freak-outs are much worse than the dropped line of output when comparing the possible problems users may see by default. --001a113f76b89fcf4a0562ea81b0--