But, I've never had to do that before (I was using nmh-1.4). I'm trying
to avoid the prospect of changing my locale and just have mhshow output
data as it did before. I suppose if it comes right down to it, I could
put a wrapper around show/next, etc...
To expand on what David said, but to put it more clearly:
nmh, prior to 1.6, got it wrong. We now get it less wrong (but still
nmh 1.6 isn't perfect).
Before, you could set the environment variable MM_CHARSET to tell nmh
what character set you supported. That existed because MH was around
before locales were invented. But now the way you indicate to all
applications which character set you support is via locale settings.
So now nmh uses the locale settings. That's a good thing! We're
behaving like other Unix applications now!
The previous version of nmh on my system didn't bother with conversion
(at least not to my knowledge) and would naively just output the
text/plain portion and let my terminal figure out what to do with
it (which occasionally left some characters unreadable, but it was
sufficient for my needs). It seems now that nmh is trying to be more
selective about what it shows rather than just being liberal about it
and showing me what is in the file. Either that or previously nmh was
more successful at converting the UTF-8 to US-ASCII.
Well, you've got it kind-of right ... what it did before was just output
stuff by default. You had to manually configure any character set conversion
and most people never bothered, and frankly I always found the fact that
you had to configure that basic function rather ridiculous. So now character
set conversion happens by default. The consensus on the mailing list was
that both of these things (automatic character set conversion and getting
your supported character set via the system locale) were definitely the
right approach.
The basic problem here is:
1) You indicate via locale settings that the character set you support is
US-ASCII.
2) nmh gamely tries to convert UTF-8 characters into US-ASCII, and fails.
3) We output an error message.
The real problem, from my perspective, is 3) ... what we should do is what
every other email program on the planet does and simply substitute a character
instead of just fail. So, we're not where we want to be, but we're getting
better.
Now, the thing that David and I don't understand is ... what, exactly,
is the problem with setting an UTF-8 locale? I kind of thought you had
to work to make that not happen, but maybe some systems don't make that
the default. If it's just generic grousing about how you didn't have
to do that before ... okay, fine, I get that. I wish we could make it
so no one ever had to change anything to make nmh work every time a new
version comes out (I know Jon Steinhart doesn't believe me, but it's
true! :-) ). But the previous nmh behavior was so wrong we really didn't
have much of a choice here. If there is some reason you can't set the
locale, we'd be intersted in hearing about it. But seriously, if your
terminal can handle UTF-8 fine, you _should_ have an UTF-8 locale set.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers