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 understand that point ... but we're also lossless if we just keep it
in the origin character set until display time. I am really trying to
understand here; this would be a serious rework, that's why I'm trying
to understand the gain.
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.
Plan 9 has the advantage that they know every application is running
under a UTF-8 locale (well, I know you know that Plan 9 doesn't really
have locales, but you know what I mean). We don't have that luxury
(I wish we did!).
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).
You had mentioned this earlier, and I took a look at it then. I did not
see anything in Bio(3) that handled character transliteration. I am
happy to be proven wrong here. I looked at:
http://man.cat-v.org/plan_9/2/bio
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers