Re: [PATCH 1/1] prompt: Fix an off-by-one in the overf check in countpromt.

[Warepire - <warepire.ml@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]

On Tue, Jan 16, 2018 at 8:32 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Tue, Jan 16, 2018 at 9:04 AM, Warepire - <warepire.ml@gmail.com> 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.