Re: badly calculated width of emoji in psql
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Jacob Champion <pchampion@vmware.com>
Cc: "pavel.stehule@gmail.com" <pavel.stehule@gmail.com>, "horikyota.ntt@gmail.com" <horikyota.ntt@gmail.com>, "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-07-19T07:46:21Z
Lists: pgsql-hackers
On Wed, Jul 07, 2021 at 06:03:34PM +0000, Jacob Champion wrote: > I would guess that's the key issue here. If we choose a particular > width for emoji characters, is there anything keeping a terminal's font > from doing something different anyway? I'd say that we are doing our best in guessing what it should be, then. One cannot predict how fonts are designed. > We could also keep the fragments as-is and generate a full interval > table, like common/unicode_combining_table.h. It looks like there's > roughly double the number of emoji intervals as combining intervals, so > hopefully adding a second binary search wouldn't be noticeably slower. Hmm. Such things have a cost, and this one sounds costly with a limited impact. What do we gain except a better visibility with psql? > In your opinion, would the current one-line patch proposal make things > strictly better than they are today, or would it have mixed results? > I'm wondering how to help this patch move forward for the current > commitfest, or if we should maybe return with feedback for now. Based on the following list, it seems to me that [u+1f300,u+0x1faff] won't capture everything, like the country flags: http://www.unicode.org/emoji/charts/full-emoji-list.html -- Michael
Commits
-
Extend collection of Unicode combining characters to beyond the BMP
- 5bc429aacb37 15.0 landed
-
Update display widths as part of updating Unicode
- bab982161e05 15.0 landed
-
Revert "Rename unicode_combining_table to unicode_width_table"
- 1563ecbc1be8 15.0 landed
-
Change mbbisearch to return the character range
- 78ab944cd4b9 15.0 landed