>I recognise that this seems to be an old issue, so I guess the short
>version of the question is has mime handling in repl (so, for example,
>non-UTF8 text being quoted in a reply turns up as UTF8, not as '=91'
>etc.) progressed at all since 2012?

Jeez Conrad, I am not sure what the failure mode is here, but we have
shipped various solutions to this problem since nmh 1.5 was released
(which was in June of 2012).  This has been discussed a lot here in
nmh-workers (especially in the run-up to the 1.5 release) and it was
mentioned in the release notes for 1.5.

Now, you're not the first person to ask, "Hey, did you guys ever fix this?"
where I replied, "Yeah, in 2012, where have you been?".  So, I guess my
question to YOU is ... what would we need to have done to make you more
aware of this?

Now, you might reasonably say something like, "Hey, I was expected it to JUST
WORK when I run repl, and that didn't happen".  Well, yeah ... the reasons
for that are complicated, and let me expand on that a bit.

Most nmh tools are not MIME-aware.  They work great on message HEADERS,
but the body is seen as one big ASCII text blob.  You might be fooled
into thinking that since "show" mostly works fine on MIME messages
then all of nmh is MIME-aware, but what is happening there is some
magic happens behind the scenes ... if show sees a MIME message it runs
mhshow(1) which is one of the few programs that IS MIME-aware.

What repl(1) does it it expects mhl(1) to format the message suitably to
generate useful reply text. mhl has never been great at this job, but
it basically fails when you have MIME content (because it is not MIME
aware).  So we have a couple of different ways to make it so you can get
something useful when you run repl on a MIME message.  But because a lot
of current configurations use mhl already and mhl is not MIME-aware, it's
hard to make it so it works right using a default configuration.  In a perfect
world we'd have mhl be MIME aware and things would just work, but we're not
there yet.



Reply via email to