Re: [Nmh-workers] nmh 1.6: character set checks and exmh compatibility

[Ken Hornstein]

>But we aren't. I am saying UTF-8 is the native internal character
>set. What happens at the boundaries becomes everyone else's problem.
>And after all the grief in this discussion over the last five+ years,
>don't you think it should be someone else's problem?

Yeah, this is the part I don't understand.  Let's say UTF-8 becomes the
native internal character set.  What is the gain?  I'm perfectly willing
to say I am missing something here.

AFAIK, it doesn't help _input_; we still have to convert upon reading a
message (even if we store messages in UTF-8, we still have to convert
the first time we get them).  It doesn't help _output_; we still need to
convert to the user's native character set.

While I understand why programs editors and terminals have a native internal
character set, we don't really need to process individual characters
like they do.  We mostly treat the string data as opaque blobs except
for a few circumstances, and those are relatively straightforward to
handle.  So, I'm really trying hard to see the gain here.  Where we tend
to run into problems is the boundary between nmh and the user; I don't
see how using UTF-8 internally fixes it.

--Ken