Re: Invisible PROMPT2
От | Thomas Munro |
---|---|
Тема | Re: Invisible PROMPT2 |
Дата | |
Msg-id | CA+hUKGJr+HZR4kCsfGiQPb=71jpdvmWZamfZb4vqGjYoph5LkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Invisible PROMPT2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Invisible PROMPT2
|
Список | pgsql-hackers |
On Tue, Nov 19, 2019 at 12:09 PM Tom Lane <tgl@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.
В списке pgsql-hackers по дате отправления: