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

[Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Sorry I did not test this.  But maybe when this starts working, we
should consider removing the progress report for large messages.

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

Yes, I have seen that and just learn about 'thread-signal'.

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

Their was no errors because those sendings did not generate any.  The
success messages appeared in the *Messages* buffer.

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

Yes this is just a start and should be tested on normal/regular usage.
As always, when I start working on this I rediscover that there is many
housekeeping done afterward by the 'smtpmail-send-it' callers (marking
as sent via mail,...): this should be taken into account too.  So it may
be encouraging but I think this is just a start.
-- 
Manuel Giraud