>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
