Ken Hornstein wrote:
Even if it can, I am unsure we can maintain
the correct column position when dealing with things like combining
characters.
That is possible. wcwidth() returns 0 for combining characters.
Do we have any specific cases where forcing a UTF-8 assumption actually
helps? The POSIX API is clumsy but the fact that it deals in the current
locale rather than UTF-8 doesn't make much difference. The code needs an
API to know stuff like how wide a string is. Knowing you have a UTF-8
encoding doesn't really gain you anything.
I think it'd be better to focus on real features. So if you want, for
example, character substitution on conversion failure and libunistring
helps then configure can check for it and disable the feature if it
isn't found. As an aside, that particular feature only sounds useful if
you're actually using a non-UTF-8 locale.
Given that nmh is BSD licenced, I'd probably favour libicu over
libunistring just for its licence. Checking on a Debian system, neither
have vast numbers of reverse dependencies.
Oliver
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers