At 11:02 +0800 02 Nov 2019, "Kevin J. McCarthy" wrote:
On Sat, Nov 02, 2019 at 09:18:14AM +0800, Kevin J. McCarthy wrote:
I don't want to over-complicate the code, but if there is a quick
fix, I'll see what I can do about this. I won't have a chance to
work on it until later this week though.
On Sat, Nov 02, 2019 at 09:18:14AM +0800, Kevin J. McCarthy wrote:
I don't want to over-complicate the code, but if there is a quick fix,
I'll see what I can do about this. I won't have a chance to work on
it until later this week though.
I put together a quick hack and pushed it up to
'kevi
On Sat, Nov 02, 2019 at 08:56:08AM +0800, Kevin J. McCarthy wrote:
I'll have to look at the code when I have more time. But I still
wonder if you sent the message, and whether the actual sent message
was corrupt or just the preview.
Okay, taking a quick peek, I see sending wouldn't work. The
On Sat, Nov 02, 2019 at 08:49:14AM +0800, Kevin J. McCarthy wrote:
Did you try previewing the message, or just sending it straight
through? It *might* work, if you don't use preview before sending.
Trying to preview will cause mutt to parse out the parts in a
receive-mode manner, which won't w
On Fri, Nov 01, 2019 at 08:05:42PM -0400, Aaron Schrab wrote:
I think it would be nice to support some "magic" MIME type that the
filter could return to indicate that no alternative should be
generated. I may want to use this for an occasional message, but not
for the vast majority of messages
Just a couple thoughts after playing around a little bit with the
$send_multipart_alternative option recently added to master.
I think it would be nice to support some "magic" MIME type that the
filter could return to indicate that no alternative should be generated.
I may want t
