Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "Kevin J. McCarthy" on 2019-10-29 at 12:58 Uhr +0800:
>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.

Makes perfect sense.

At the risk of overcomplicating things at this stage, I do want to 
put one more idea out there, which is that instead of the script 
returning content of a specific type, and thus always with the same 
content type (unless the filter script is interactive of sorts), 
what about a command or option that I can use to instruct mutt to 
generate an alternative of a given MIME type, which is then passed 
to the script, and the return data assumed as such.

Now, I could configure mutt to always add a text/html alternative, 
but also have a command from the compose menu allowing me to add 
e.g. text/enriched, or application/pdf.

>>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.

The more I think about this, the less I think this should be an 
option. Even `$fcc_attach` is already quite a problem, especially 
since it means that the message stored locally isn't the same as the 
one you sent, with a different GPG signature and all.

>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.

… but not on messages that are being forwarded as attachments. Those 
don't get touched, right?

-- 
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
who's general failure, and why's he reading my disk?
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20191029/7d696918/attachment.asc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20191029/7d696918/attachment.html>