Re: [Nmh-workers] nmh internals: full MIME integration

[Ken Hornstein]

>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