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: Wed, 01 Nov 2023 19:06:08 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   . I'm not sure I understand how will the success/failure of sending
> >     be communicated back to the callers.  Currently, when the sending
> >     succeeds, there's a message in echo-area, and if the message was a
> >     reply, then Emacs marks the original message as "have been replied
> >     to".  How will this work with async sending?
> 
> The progress and "Sending email done" still shows in echo-area and
> *Messages* buffer but asynchronously.

What happens if the foreground Lisp program displays something in the
echo-area at that time?  I'm asking because I don't think it's a good
idea to show this from a background thread.

> >   . What happens if sending fails for some reason?  It could be that
> >     the problem is detected by smtpmail itself, or it could be that
> >     some low-level code signals an error -- what happens in both
> >     cases?
> 
> Some errors should be handled in 'smtpmail-send-mail' and signal by
> calling (error).  But other errors won't be.  For instance, I tried to
> send a mail to a non existent address and I get no error whatsoever: the
> buffer is also called "*sent ...*"

Signaling an error in a non-main thread causes the thread exit
silently, with the error stored in a variable, so something should be
done to show the error to the user.

> >   . What happens if another message is sent while the previous one is
> >     still being sent?
> 
> That I have tested.  It works because the temporary buffer where
> everything takes place is generated by 'generate-new-buffer' which
> creates a unique name if needed.

So you have several threads sending at the same time?  If so, what
happens with their errors and success messages?

> >     For that matter, how long did it take for the background thread to
> >     send the message?  If that was short enough, like 1 sec or so, I
> >     suggest to test this with sending a larger message, like a message
> >     with a large attachment.  That's because the most important
> >     situation where async sending is valuable is when it takes a long
> >     time to send a message, either because it's a large message or
> >     because the connection is slow or unreliable.
> 
> Yes I have tested with longer to send message otherwise I would not be
> able to see the asynchronous process.

If you don't see problems with responsiveness, this is encouraging.
IME, such problems happen quite frequently, for example if you type
during the time the background thread does its job.

Thanks.