Re: [Nmh-workers] question about encoded recipient names

[Ken Hornstein]

>as for deprecating MM_CHARSET entirely...  i suppose that's okay.  but
>for arguments sake, say i had a non-utf8-aware editor, or pager, or
>terminal program -- it's a lot easier for me to invoke an mh program
>with MM_CHARSET=us-ascii than it is to figure out which locale setting
>to undo, and what to set it to.  i suppose that's not really an excuse
>for maintaining an obsolete mechanism, but it seems like simply
>documenting MM_CHARSET as being intended as a fallback mechanism which
>might be useful in unusual circumstances would be less work than
>removing it.

Well, it occurs to me that there are some issues with MM_CHARSET that
might be obvious at first glance.

MM_CHARSET is used to decide whether or not a character set can be
displayed "natively" without using iconv, as the target character
set used by iconv to convert text to, and as to what mhbuild will
use to mark text when it creates text MIME parts.

But we've been putting more intelligence into nmh in terms of
handling characters, especially with multibyte character sets; for
those we use the system functions (like isspace(), iscntrl(), and
the wide character routines).  Those don't know about MM_CHARSET;
they use the operating system locale.  So it's easy to imagine that
setting MM_CHARSET to something that doesn't match the character set
used by your current locale then weird stuff could happen.  Maybe it's
not a big problem now, but to me it's just another reason to transition
to using the locale solely (unless there's a good reason not to).

And if you want to run a program with a different character set, it's
easy to just do something like "LC_ALL=en_us.UTF-8 scan".

--Ken