On Fri, Nov 15, 2019 at 3:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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.