Re: ZWJ paste from clipboard problem (unicode)

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2025-04-01 13:23:27 +0200, Oliver Kiddle wrote:
> The problem for zsh remains that wcwidth is the libc interface that
> provides a way to find a correspondence between wide characters (i.e.
> unicode code points) and graphemes. There's a lot of limitations in
> what libc provides. Most terminals also use wcwidth() so share the same
> limitations meaning that behaviour is at least consistent.
> 
> So zsh would need to either depend on some additional external library
> or we need to fetch tables of unicode code points and generate our own
> tables to classify them.

If you mean hard-coded tables (not based on what wcwidth provides),
this is a bad idea. This was what GNU Screen was doing and led to
recurrent display issues, until this got replaced by wcwidth:

  https://savannah.gnu.org/bugs/?63634

> libICU is the long-standing C library for this but it's a huge
> monster dating from a time when people expected 16-bits to be
> enough.
[...]

and there seem to be portability issues with libICU.
In the libxml2 Debian changelog:

  * Don't build with ICU. Closes: #1092484.

    libxml's README.md states:

    [ICU](https://icu.unicode.org/), a Unicode library. Mainly
    useful as an alternative to iconv on Windows. Unnecessary
    on most other systems.

    ICU 76.1 requires to be built with -std=c++17 or -std=gnu++17 or
    higher.  However including the ICU headers in the libxml2 headers,
    breaks builds with older C++ standards, most likely leading to
    some unrelated build failures for packages that don't rely on ICU,
    but are using libxml2.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)