Paul Fox wrote:
can nmh decode UTF or otherwise-encoded headers? it's not that
Yes. See the decode function in the mh-format manual page. It has a few
limitations however. It doesn't use iconv or similar to convert headers
to the current encoding. So you need to use a UTF-8 locale and set
Paul Fox wrote:
can nmh decode UTF or otherwise-encoded headers? it's not that
Yes. See the decode function in the mh-format manual page. It has a few
limitations however. It doesn't use iconv or similar to convert headers
to the current encoding. So you need to use a UTF-8
Paul Fox wrote:
can nmh decode UTF or otherwise-encoded headers? it's not that
Yes. See the decode function in the mh-format manual page. It has a few
limitations however. It doesn't use iconv or similar to convert headers
to the current encoding. So you need to use a
Yes. See the decode function in the mh-format manual page. It has a few
limitations however. It doesn't use iconv or similar to convert headers
to the current encoding. So you need to use a UTF-8 locale and set the
MM_CHARSET environment variable to UTF-8. That means that it
You wrote:
i guess i was thinking of a wrapper for scan or show that took care
of setting up the locale and charset, either via argument for manually
choosing, or maybe even by examining the message and then figuring out
what locale/charset it should probably use, this time.
It's probably
What do you consider a nice solution? I use the method as described
by Oliver (actually that's the default of the debian package). It works
satisfactory but unfortunately we have a wild mixture of latin1 and latin9
in europe (thanks to MS windows not being able or willing to adapt to
On Mon, 14 Feb 2005 19:35:36 +0100, Harald Geyer said:
Obviously any script which tries to do the above runs into the same
problem that prevents nmh from doing it itself: The script would need
to know which charsets the terminal can handle and how to tell it.
Also changing the terminal might
I guess it would be much easier und less prone to error to just
implement transcoding of messages through iconv instead of trying
to adapt the display on a per message basis.
In general, you *can't* do a good job of using iconv to mash things between
the various iso8859-* charsets.
i've never seen the behavior you describe since adopting
MH back in 1982 or so. at least in The Good Ol' Days,
the refile operation was done with a link-unlink syscall pair and
there is essentially no way for that to impact the contents
of a file.
in fact, i doubt seriously that the contents of
I use nmh-1.0.4 in FreeBSD UNIX and have noticed that the
refile function occasionally eats a message. It moves it from one
folder to another all right, but what ends up in the receiving folder
is a file containing all 0xFF's.
Sounds like it fails to open it without noticing or
it seems that this patch relies on other local changes you've
made to your tree -- i went searching for get_charset with google,
and came up with a message you sent to this list on january 24
which contained such a routine, in different mime-related patch. :-)
paul
i guess i was thinking of
11 matches
Mail list logo
