Re: [Nmh-workers] New mhbuild directives

[Ken Hornstein]

>> In terms of implementation ... it should be pretty easy.  The magic happens
>> in build_mime() and setup_attach_content() in mhbuildsbr.c.  Seems like
>> the easiest thing to do is add a flag to "struct attach_list" to indicate
>> if this attachment is inline or not, and make setup_attach_content()
>> take that flag and DTRT.
>
>So now the user has to memorize an internal-to-the-source-code table to 
>know when she has to override the built-in inline/attach defaults?  That's 
>just nuts.

Sigh.  I didn't say that.

Right now we have an Attach: header.  It always uses a disposition of
"attachment" ... unless it's text/calendar (because David discovered
that calendar replies aren't processed unless they're inline).

In addition to having text/calendar, we have other people asking for
the ability to attach with a different disposition (Paul is only the
latest).  That suggests to me we need to add that capability.

>However, the mhbuild process could certainly be simplified.  The existing 
>syntax is powerful, but something of a pain to use.  Having to know the 
>MIME content type for an attachment is burdensome, not to mention a likely 
>source of errors.  This problem could be addressed with a new pair of 
>directives:
>
>   #attach ;attribute <id> (comment) [description] filename

I will note that I suggested this exact thing in December (well, without
the extra options); after much hashing on the mailing list, we decided to
come up with the Attach header instesad.

It seems logical to me to:

- Remove the special case for text/calendar in the source code.
- Implement a new "Inline" header.
- Implement a new "inline" command at the WhatNow prompt.

--Ken