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

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: 63311@debbugs.gnu.org
> Date: Wed, 01 Nov 2023 20:55:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.

I think when messages are sent in the background, there should be a
different series of messages: one at the beginning, when the thread is
launched, and one when the thread exits.  Both of these should be
output by the main thread, not the thread which sends.  The sending
progress messages will not be shown, since they are mostly useless
anyway (if the user wants the sending to be in the background, it
generally means he/she doesn't care much about the progress, since
Emacs is not waiting for the sending to complete).  If we need more
detailed messages in some cases, we could have a special buffer which
the user could then view 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.

One more reason to move the messages to the main thread, to avoid
threads "fighting" for the echo area.

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

Right, thanks.

When this is available, I will probably become a heavy user of this
feature.  It should probably be an opt-in feature initially, so as to
let people try it without disrupting their production workflows too
much.