>> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
