Hi Kevin,Thanks for sharing your thoughts and plans on this. This all reads really well, and I think it would go most of the way towards the ideal solution.
I have a couple of points/questions about some of the things you propose:
If there were an error sending, the alternative would be stripped before returning to the compose menu. So it would not be exposed to the compose menu. I *might* add a function to preview the output as raw text and via mime from the compose menu though.
The ability to preview sounds great, and I would greatly appreciate it.
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?
Anyway, that's my current plan. The problem is cleaning up some other parts of mutt to deal with bouncing, reuse as a template, etc.
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.
However — and I just experienced this — forwarding a message as attachment now means that it'll be plain-text only.
Processing a message to be attached, or a message to be bounced, seems to me like a really bad idea, especially since it should only ever be applied to messages that were locally authored. Maybe this would mean storing with the locally recorded message a little bit of metadata suggesting that Mutt generated an alternative part for this message when it was sent?
Yeah, this can get ugly fast, and maybe the right way forward is instead to store the generated content when saving a message locally, but to teach Mutt to discard any multipart/alternative non-text/plain part when reusing a message as a template, similarly to how that part is discarded on error before it's returned to the compose menu?
Best regards, -- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the english take english for granted. but if we explore its paradoxes, we find that quicksand can work slowly. spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
