On Tue, Nov 19, 2019 at 12:09 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > You should follow the logic in pg_wcswidth: compute PQmblen() first, > and bail out if it's more than the remaining string length, otherwise > it's ok to apply PQdsplen().
Got it. I was worried that it wasn't safe to call even PQmblen(), because I didn't know a fact about all encodings: as described in the comment of pg_gb18030_mblen(), all implementations read only the first byte to determine the length, except for GB18030 which reads the second byte too, and that's OK because there's always a null terminator. > It might be a good idea to explicitly initialize last_prompt1_width to > zero, for clarity. > > Should the user docs explicitly say "of the same width as the most recent > output of PROMPT1", as you have in the comments? That seems a more > precise specification, and it will eliminate some questions people will > otherwise ask. > > LGTM otherwise. Done, and pushed. I also skipped negative results from PQdsplen like pg_wcswidth() does (that oversight explained why a non-readline build showed the correct alignment for PROMPT1 '%[%033[1m%]%M %n@%/%R%[%033[0m%]%# ' by strange concindence). Thanks all for the feedback. I think the new bikeshed colour looks good.
