[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mhshow: unable to convert character set of...

From: Ken Hornstein
Subject: Re: [Nmh-workers] mhshow: unable to convert character set of...
Date: Fri, 06 Feb 2015 09:03:17 -0500

>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
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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]