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

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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