>Since us-ascii is a perfect subset of utf-8, is there any reason that nmh
>couldn't take a look at the locale, and if it is us-ascii just use uft-8?
Well ... us-ascii is ALSO a perfect subset of iso-8859-1. Or a whole
lot of character sets, actually. Some people would argue those are more
I realize we could check to see if a character is a valid utf-8 multibyte
sequence and that's got a very high probability of always being right. But
what if it isn't; what should we do then?
Also, it kind of strikes me as the wrong solution, and not just because
of the additional complexity. The locale setting is supposed to
indicate to utilities which character set you're using. So we (rather
reasonably, I would argue) use that in nmh to determine the character
set for input and display. If you're putting an 8-bit character into
a message when you've told us that you are always going to be sending
US-ASCII ... well, what are we supposed to do? That seems like an error
condition to me. You can explicitly override the character set in your
draft for a single message (see mhbuild(1)) if you want to do something
different for individual messages, but absent that I think going with the
locale character set is the only solution.
Nmh-workers mailing list