Re: badly calculated width of emoji in psql

Jacob Champion <pchampion@vmware.com>

From: Jacob Champion <pchampion@vmware.com>
To: "john.naylor@enterprisedb.com" <john.naylor@enterprisedb.com>, "pavel.stehule@gmail.com" <pavel.stehule@gmail.com>
Cc: "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>, "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>
Date: 2021-08-12T16:54:02Z
Lists: pgsql-hackers
On Thu, 2021-08-12 at 12:36 -0400, John Naylor wrote:
> I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac, in case that matters) and the example shown at the top of the thread shows no difference:
> 
> john.naylor=# \pset border 2
> Border style is 2.
> john.naylor=# SELECT U&'\+01F603';
> +----------+
> | ?column? |
> +----------+
> | ๐Ÿ˜ƒ        |
> +----------+
> (1 row)
> 
> (In case it doesn't render locally, the right bar in the result cell is still shifted to the right.
> 
> What is the expected context to show a behavior change?

There shouldn't be anything special. (If your terminal was set up to
display emoji in single columns, that would cause alignment issues, but
in the opposite direction to the one you're seeing.)

> Does one need some specific terminal or setting?

In your case, an incorrect number of spaces are being printed, so it
shouldn't have anything to do with your terminal settings.

Was this a clean build? Perhaps I've introduced (or exacerbated) a
dependency bug in the Makefile? The patch doing nothing is a surprising
result given the code change.

--Jacob

Commits

  1. Extend collection of Unicode combining characters to beyond the BMP

  2. Update display widths as part of updating Unicode

  3. Revert "Rename unicode_combining_table to unicode_width_table"

  4. Change mbbisearch to return the character range