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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers