bug#63311: 30.0.50; [PATCH] smtpmail-send-it split

[Eli Zaretskii <eliz@gnu.org>]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 63311@debbugs.gnu.org
> Date: Sun, 05 Nov 2023 15:24:50 +0100
> 
> Hi Eli,
> 
> I'm still struggling with making 'smtpmail-send-it' async.  As I'm using
> message.el, I'm trying to make it work here.  But message.el in written
> in such way that it is quite hard to make it work with a threaded
> 'smtpmail-send-it' call.
> 
> And then, from a message buffer (with a quite large attachment), I've
> just evaluted the following: (make-thread #'message-send)... and
> everything went ok:
>            - Emacs is still responsive: I could switch to other
>              buffers, request the status of a VC handled file.
>              
>            - When the message is finally sent, the buffer is renamed
>              accordingly and tagged as sent via mail.
> 
> So my question is this one: instead of making 'smtpmail-send-it'
> threaded why not have a threaded version of toplevel commands (such as
> 'message-send')?  We could hopefully do the same for sendmail.el.  Of
> course, we should have it as opt-in behind customs
> (message-send-in-background and/or mail-send-in-background?)
> 
> As for when something goes wrong and we end up in an 'error' call, maybe
> we should fix how 'error' behave inside a thread.  What am I missing?

Nothing, AFAIU.  Instead of making smtpmail-send-it optionally working
asynchronously, it should be perfectly valid to have a separate
function called, say, message-send-asynchronously, which would work
with background threads and implement the same protocol as the other
MUA's send-it functions do.