On Tue, Oct 29, 2019 at 12:41:44PM +1300, martin f krafft wrote:
Script output would be the content-type, a blank line, then the generated content.This makes me itch, but I cannot really devise a better approach. I want to say that the script needs to return the complete MIME part, including Content-Transfer-Encoding and other headers, or are you confident that Mutt can deduce all these parameters from the generated content?
The part creation (and removal) will be in Mutt's pipeline, and so will follow normal processing that Mutt does. That include encoding, delimiters, charset conversion, etc. So I would like the script to simply produce the HTML (or PDF, or whatever) output, without trying to "mailify" the output.
I think it would be okay for a charset to optionally be included in the content-type. I have to think about whether to force-charset in that case, or still respect $send_charset.
But I don't think allowing other headers would help. Mutt can determine the best content-encoding, and I think it's fair to set disposition to inline. If the approach turns out to be insufficient, we can add features.
Reusing as a template would be resolved if we kept a local record of the messages without the generated content, similar to how `$fcc_attach` removes the attachments before storing.
For this iteration, I didn't plan on going here. $fcc_attach would still just remove attachments, the main content would be stored as it were generated (i.e. including multipart/alternatives). Maybe in the next iteration I could add an option to strip the alternative.
However — and I just experienced this — forwarding a message as attachment now means that it'll be plain-text only.
Yes, this is one of the places I need to look at. My plan is the simplest, as you mentioned: discard the alternative when generating anything that goes through the compose menu.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
