Re: [Nmh-workers] Items for nmh 1.7

[Ken Hornstein]

>You could use profile entries like mhshow-charset-iso-8859-1 to run a
>script that would run iconv. The script would sometimes get a filename
>and sometimes a command from, e.g, the mhshow-show-text/html profile
>entry so it wasn't simple. It is much much simpler now so thanks for the
>changes. It doesn't reflow text but that's easy from vim with formatprg
>set to par.

I was aware of that, but in practice I found it terrible since you had
to explicitly list every character set.

>This is more flexible than what we have for mhshow (being able to match
>content-type and disposition flags). So this could also benefit mhshow.
>The trailing ",flowed" could perhaps be handled instead as something
>like "filter=par". But, it then starts looking inconsistent with the use of
>things like mhshow-show-text/html which is specifying a sort-of external
>filter in a different way.

Well, this is still a work in progress.  I was idly thinking this
morning about a concept called "modules".  You could have modules for
different content types, modules for different transfer encodings,
modules for charset conversions, etc etc.  They'd be strung together to
generate the content however you would like.  Well, the underlying
MIME structure really means that you'd have to deal with them in a certain
order.  You need to decode the transfer encoding first, do any character
set conversion next, then feed it into your content handler.  My thinking
was that you could substitute any of your own modules for the nmh internal
ones at some point.  Again, this is all sort of vague.

>> body:match,ct=text/plain,inline:display
>> body:match,attachment:marker="Part %{part} %{content-type}"
>
>One thought with the marker is that it could be inserted in the form of
>a #forw mhbuild directive. You could then choose to include individual
>attachments in a reply (or forward). The only problem is that #forw
>doesn't support selecting individual message parts: only a whole
>message. Currently forwarding messages with attachments is something
>that could be better which this might achieve.

The big problem I see with this is you can't forward a specific
attachment from a #forw directive ... also, I think that putting an
mhbuild directive in the draft is kind of lousy.  Fine if people
want to do it, but not something I'd want to do regularly.  But the
functionality would undoubtedly be useful; we'd just need to think about
how to make it work.

--Ken