nmh-workers
[Top] [All Lists]

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

2012-06-10 12:54:12
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>