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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
