nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] 1.5 release and better repl/MIME handling


From: Ken Hornstein
Subject: Re: [Nmh-workers] 1.5 release and better repl/MIME handling
Date: Sat, 31 Mar 2012 12:45:29 -0400

>> But that got me to thinking - maybe I could have a more intelligent
>> formatproc that could handle MIME?
>
>I haven’t been following the discussion very closely, but what strikes
>me is, are you saying that it’s difficult to arrange (within mh) that
>a different formatproc is called (for each mime part) depending on the
>mime type? So your perl script does this?

Sorta.  Here are the details (and just for the record, this the first
message I've replied to using my new replyfilter).

If you use -format with repl, it calls mhl to build the body of the reply
draft.  mhl is _not_ MIME-aware, and that's the core problem.  All it
really knows about is header components.  It has a special "body" component
that refers to the whole body.  You can see this in how nmh deals with
quoting the reply: to prefix a ">", you tag the body component with the
name of ">" and internally mhl thinks of the body as one super-long header.

So what I did was create a special "format" option that lets you
feed the body component (and it ONLY works with the body component)
through an external filter program.  The recent change I added to
it was to make it so you can specify arguments to the external filter
via the mhl specification file, and those arguments can be extracted out
of the message headers via mh-format (and hoo boy, writing THAT code was
a pain).

You could write a program to do anything you want with the body of the
message.  What mine does is this:

- Decodes quoted-printable and base64 text, and feeds those parts to
  another filter program (I defaulted to "par").
- Leaves regular text/plain parts alone.
- Picks the text/plain parts out of multipart/alternative messages.
- Puts marker in the reply message for other MIME types.

In a perfect world we'd make mhl MIME-aware and have a format file which
described what to do with different MIME types.  But I'd rather not hold
up 1.5 for that.

--Ken



reply via email to

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