On Jul 28, 2014, at 7:29 PM, Ken Hornstein <kenh(_at_)pobox(_dot_)com> wrote:
It's not even that ... consider the existing APIs. If we consider iconv(3) to be a required dependency (something I'm seriously considering) then it's not so bad. But ... I guess I don't see the gain converting everything internally to UTF-8; you're still converting it to the local character set in most cases.
The reason why I like the idea of using utf-8 internally is that it encompasses anything we can (reasonably) expect to see. It makes us "lossless" internally. If the display side of the environment can't handle things, well, too bad. We can't reprogram people's terminals or character sets for them. But we *can* make a valiant effort to downgrade the representation to something they can deal with, if that's at all possible. I have to say I am a big fan of how Plan 9 handles this. They didn't teach the mail software about unicode and character sets, they taught the C runtime about utf-8, and everything else just came along for the ride. I know this will make everyone freak out, but let me say it anyway: if we imported the Plan 9 Bio library and switched over to that, most of these issues would vanish. It would make everything natively use utf-8 internally, and as with upas, we could transliterate between external character sets by invoking tcs(1). Switching to Bio(3) would likely be less work than a full-on iconv+wide-characters conversion, and upas has a 20 year track record that shows the scheme works. --lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org https://lists.nongnu.org/mailman/listinfo/nmh-workers