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

[Manuel Giraud]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: 63311@debbugs.gnu.org
>> Date: Wed, 01 Nov 2023 13:35:45 +0100
>> 
>> I'm reviving this old bug report because I think I have made some
>> progress.  Here is a new patch that tries to send mail asynchronously.
>> This seems to work for me but, of course, it needs testing, testing and
>> even more testing.
>
> Thank you for working on this.
>
> I have several questions about it:
>
>   . 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.  As for the "have been replied
too" part, it happens right after 'C-c C-c' so a message that should
error later down the line will be named as "*sent reply...": this is a
problem.

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

>   . With which MUA are you testing this?

I'm testing gnus and message-mode.

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

>   . What did you try to do in Emacs while the message was being sent,
>     and did you see any problems with the foreground responsiveness?

I did not do some intensive usage just moving to other buffers.  I've
not seen any problem with responsiveness.

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