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?
Non-UTF8 messages appear fine when I 'show' them, but when I 'repl' all
non-UTF8 characters are in '=91'/'=92'/'=96' format. The main offenders
are Windows-1252 messages. Any suggestions where I should look for
what's causing this? I'm using system default mhl.format and mhl.reply,
which respectively have the following 'body' lines:
Conrad Hughes writes:
> .. at first I thought that mhfixmsg might help, but things seem to end
> up in even more of a mess after (for example) 'mhfixmsg -reformat
Have you also tried `mhfixmsg -textcharset utf-8'?
> > Have you also tried `mhfixmsg -textcharset utf-8'?
> I hadn't, but it doesn't seem to improve my results, with or without
> various combinations of -reformat and -replacetextplain.
One example that doesn't work would give us more chance of helping.
> Is mhfixmsg the most likely tool for this job then: no good solution
> has been produced solely within repl?
repl(1) has -fmtproc, and /usr/share/doc/nmh/contrib/replyfilter is a
Perl script to be used with it. You might prefer that approach.
Searching for `replyfilter' in the archives turns up various
> repl(1) has -fmtproc, and /usr/share/doc/nmh/contrib/replyfilter is a
> Perl script to be used with it.
Another approach is to use the repl -convertargs switch. See
.../share/doc/nmh/contrib/replaliases for shell aliases that make
it easy to use. I source that file and then use either rt
or rtm if I am or am not, respectively, going to add attachments
with whatnow(1) attach.
>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