use uc_width() instead of wcwidth()

[tstack]

The wcwidth() implementation on macos is ancient and doesn't recognize many emojis. It looks like notcurses is already linking with libunistring and there is a uc_width() (and related) functions for computing the width. It might be worth investigating using that instead.

(I made the switch in my local copy of notcurses and it seems to work. But, be warned that libunistring has their own "stdint.h" that does a #define in32_t that really screws the world up. So, including the "uniwidth.h" header in "notcurses.h" will wreck some stuff.)

[dankamongmen]

interesting! is this a recent addition to libunistring? how fast is it? do we expect wcwidth() to ever get fixed? can you provide some instances where glibc/musl wcwidth() is definitely broken (i.e. for all fonts you can find etc?). thanks!

[dankamongmen]

if this fixed up the mojibake demo, that would be quite compelling.

[dankamongmen]

one thing to remember is we don't want some Platonic width. ideally we would get the width as emitted by the font stack, since that's what truly decides it. since we can't get that via any means of which i'm aware, the next best thing is the width as the terminal thinks, so that we're on the same page/plane. which i suspect is more likely to be wcwidth() than uc_wcwidth()...

[dankamongmen]

i see no uc_wcwidth() nor any other function with width in the name in debian's installation of libunistring 1.3-1...

[tstack]

is this a recent addition to libunistring?

I don't think so. But, they have a crazy build, so I don't know when it was introduced.

do we expect wcwidth() to ever get fixed?

It really doesn't seem like it's going to be fixed since it's been like this for quite a few years. The test program below uses https://www.compart.com/en/unicode/U+2705, which was added in 2010.

can you provide some instances where glibc/musl wcwidth() is definitely broken (i.e. for all fonts you can find etc?).

Some of my users were complaining in here -- tstack/lnav#1134

They're complaining about the version of lnav that uses ncurses. I think if wcwidth() returns -1, ncurses won't print anything.

Here is a simple test program:

#include <stdio.h>
#include <wchar.h>
#include <uniwidth.h>

int main()
{
    wchar_t ch = 0x2705;

    printf("white heavy check \u2705 wcwidth() = %d; uc_width() = %d\n", wcwidth(ch), uc_width(ch, "UTF-8"));
}

On macos 15.2, the output looks like the following in Terminal.app:

i see no uc_wcwidth() nor any other function with width in the name in debian's installation of libunistring 1.3-1...

It's uc_width(), not uc_wcwidth().

[dankamongmen]

ahhh indeed thanks