Re: [dev] [st] Emojis

From: Eric Pruitt <eric.pruitt_AT_gmail.com>
Date: Mon, 6 Nov 2017 21:19:20 -0800

On Sun, Sep 17, 2017 at 07:01:58PM -0400, Gary Allen Vollink wrote:
> I noted in a previous thread [
> https://lists.suckless.org/dev/1709/32306.html ] that wcwidth was
> recently fixed/updated in Linux's glibc: [
> https://lists.gnu.org/archive/html/info-gnu/2017-08/msg00000.html ].
> Ultimately, this (and recompiling everything that links it statically)
> is the RIGHT way to fix all of these issues.

I decided to tackle my own character width problems again and finally
got them sorted out thanks in part to this message. The solution for me
was a bit different: I statically compile various command line tools
that I commonly use -- GNU Awk, tmux and Bash to name a few -- using
musl. Since st depends on X11, I always build it dynamically using my
Linux distro's default libc which is always GNU libc. As far as I can
tell, musl's wcwidth(3) hasn't been updated in a very long time. I
gutted the original implementation and made it a thin wrapper around
utf8proc (https://github.com/JuliaLang/utf8proc). Here is the
corresponding code in my Makefile that does this:

    (cd $(UTF8PROC) && cpp -P -E utf8proc.c) > $(MUSL)/src/ctype/wcwidth.c
    printf '%s\n' >> $(MUSL)/src/ctype/wcwidth.c \
        '#include <wchar.h>' \
        'int wcwidth(wchar_t wc)' \
        '{' \
        ' return utf8proc_charwidth((utf8proc_int32_t) wc);' \
        '}'

The utf8proc_charwidth function returns 0 in cases where wcwidth(3)
would return -1, but this has not been a problem for me in practice
because all of the text I care about is well-formed UTF8.

Eric
Received on Tue Nov 07 2017 - 06:19:20 CET

This archive was generated by hypermail 2.3.0 : Tue Nov 07 2017 - 06:24:16 CET