Re: [Nmh-workers] Time to branch 1.6?

[Jerrad Pierce]

>If the issue is that we need to un-qp some HTML content that results in
>a line length > 998, but then that HTML will be converted to plain text that
>presumably won't have long line, then that would be fine

Precisely.

>It does.  At this point, I don't understand your problem.
>mhfixmsg adds text/plain parts all the time for me.  A
>significant fraction of my incoming mail is text/html.
>It's all handled properly, even if the original content is
>binary, and then I see the same warning as you.

It recreates text/plain alternative parts for me, and sometimes
creates new ones, but it fails to create them for HTML parts
with long lines, as Ken recapped above. As I understand it you
previously stated that this was dependent on the ability of nmh's
MIME parser to read long lines. I was just now suggesting that
that was not necessarily a dependency, since the decoded HTML
with lon lines need not be comitted back to disk, but simply
used to generate the new plain text part.


If I run:

  mhfixmg -textcharset UTF-8 -decodetext 8bit -reformat -replacetextplain

on this message:

  http://pthbb.org/~belg4mit/1394

the file is unmodified, and I get the aforementioned diagnostics with -verbose