Re: Invisible PROMPT2 - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Invisible PROMPT2
Date
Msg-id CA+hUKGJ8BOaz0AJ0B3Z=0QsNq3zCB_ZTx=8mcE-t6-D3p=mRWQ@mail.gmail.com
Whole thread Raw
In response to Re: Invisible PROMPT2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Invisible PROMPT2  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Fri, Nov 15, 2019 at 3:58 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > This seems assuming %x are a kind of stable (until semicolon)
> > function. But at least %`..` can be volatile.  So, I think the %w
> > thing in PROMPT2 should be able to refer the actual prompt string
> > resulted from PROMPT1.
>
> Oh, that's a good point.  But it actually leads to a much simpler
> definition and implementation than the other ideas we've kicked
> around: define %w as "whitespace equal to the length of the
> last-generated PROMPT1 string (initially empty)", and we just
> have to save PROMPT1 each time we generate it.
>
> Except ... I'm not sure how to deal with hidden escape sequences.
> We should probably assume that anything inside %[...%] has width
> zero, but how would we remember that?
>
> Maybe count the width of non-escape characters whenever we
> generate PROMPT1, and just save that number not the string?
> It'd add overhead that's useless when there's no %w, but
> probably not enough to care about.

Nice idea.  Here's one like that, that just does the counting at the
end and looks out for readline control codes.  It's pretty naive about
what "width" means though: you'll get two spaces for UTF-8 encoded é,
and I suppose a complete implementation would know about the half
width/full width thing for Chinese and Japanese etc.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: could not stat promote trigger file leads to shutdown
Next
From: David Fetter
Date:
Subject: Re: Reverse collations (initially for making keyset pagination covermore cases)