[Top][All Lists]

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

[Nmh-workers] Fixing decoding of quoted messages in replies

From: markus schnalke
Subject: [Nmh-workers] Fixing decoding of quoted messages in replies
Date: Tue, 26 Oct 2010 19:25:59 +0200
User-agent: nmh 1.3

Hoi nmh workers,

during the next weeks I intend to fix the annoying problem of still
encoded message text in quoted replies. The problem appears when
    repl -format
on a message with Content-Transfer-Encoding like quoted-printable or

See also the thread ``base64 message body decode when replying???'' in
comp.mail.mh starting 2010-03-22.

AFAIK this problem is still unsolved. I only found a hack in the FAQ:

    Subject: 05.16 How can I convert quoted-printable to 8bit in
                   quoted text in replies?
    From: Jarle F. Greipsland <jarle at idt.unit.no>
    Date: 22 Aug 1995 10:42:07 +0200

My experience shows that this problem makes nmh unusable to many
people who consider giving nmh a try, hence I search for a real

Has anyone of you already worked on this? Has nayone information that
can help me?

My research up to now showed that mhl(1) is the point where the
processing of the quoted message is done. There already exists a
decode function (see mhl(1)) which currently is only for header
decoding. Either this one could be extended to also decode content
transfer encodings or a second decoding function could be added.

For mhshow(1) transfer encoding decoders exist already (openQuoted()
in uip/mhparse.c for instance). Maybe these can be used.

I appreciate comments and suggestions.

Further more, two related problems:

(1) Showing messages with different charsets requires a line like
    mhshow-charset-iso-8859-1: iconv -f iso-8859-1 | %s
in the profile if your terminal is on UTF-8. It might be worth to
include such processing directly into nmh in order to make it more
usable out-of-the-box. Iconv is already available (if compiled in).

(2) Header fields that include non-ASCII characters are not
automatically RFC2047-encoded as seems to be good.

For users in non-English speaking countries such issues matter much.
Using nmh though is currently pretty tough. ;-)


reply via email to

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