From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Date: Wed, 01 Nov 2023 21:29:43 +0200 Message-ID: <83r0l98e6w.fsf@gnu.org> References: <87jzxmsyyr.fsf@ledu-giraud.fr> <83ttwqhahy.fsf@gnu.org> <874joq34bk.fsf@ledu-giraud.fr> <83o7mygevr.fsf@gnu.org> <87wn1hzv9j.fsf@ledu-giraud.fr> <871qjoe7cw.fsf@ledu-giraud.fr> <837ctf575q.fsf@gnu.org> <87ilcypot3.fsf@ledu-giraud.fr> <83pm763y3r.fsf@gnu.org> <87h6si5aor.fsf@ledu-giraud.fr> <83a5ya3u16.fsf@gnu.org> <871qjm56ej.fsf@ledu-giraud.fr> <87r0l9ejmm.fsf@ledu-giraud.fr> <834ji5aatw.fsf@gnu.org> <87bkcde4bz.fsf@ledu-giraud.fr> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27345"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63311@debbugs.gnu.org To: Manuel Giraud Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 01 20:31:03 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qyGvd-0006tr-E2 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Nov 2023 20:31:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyGvK-0008TE-QR; Wed, 01 Nov 2023 15:30:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyGv5-0008R3-F2 for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 15:30:38 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qyGv5-0002fc-78 for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 15:30:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyGvd-0008J3-M9 for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 15:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 19:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63311 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169886704631899 (code B ref 63311); Wed, 01 Nov 2023 19:31:01 +0000 Original-Received: (at 63311) by debbugs.gnu.org; 1 Nov 2023 19:30:46 +0000 Original-Received: from localhost ([127.0.0.1]:52649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyGvJ-0008IJ-W8 for submit@debbugs.gnu.org; Wed, 01 Nov 2023 15:30:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyGvD-0008Hu-Ut for 63311@debbugs.gnu.org; Wed, 01 Nov 2023 15:30:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyGuZ-0002IF-RP; Wed, 01 Nov 2023 15:29:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qX+WRnbJIt/MdfdQsvw0yxz+CfizhfwH1ZjDJ8g+M/8=; b=hvLZ5kFI7XaC Eh6KbppEktLhhYubq8+xTXcN6i9UC7sVZt9V9xLf+XNno4YECMwfye8FkkjEtJTKkDIF6jfy1ABdV XmiMu/wMV4WWKD42kkaqf7dpL4W2eBeEGA4dp/ai6k5HIKlOU/VXs8qxUMxQ0g+bO4hq7CZF299qI na9kJoycAYgR32cJMoXZP5r3hDHBUSHerkpU2Er6c1Ir3S5ZLCnp00rWPtPQxOr6fK1VHR+SOqb/i gC9dRllN35LT+WQA834Eg+UyDq1FsFe7p5+jBHOYM3ZObhzhJvscSrfdCFsGZv9JkRIACjqUcI92n INCVDgIT/06DeDXZT7ehXA==; In-Reply-To: <87bkcde4bz.fsf@ledu-giraud.fr> (message from Manuel Giraud on Wed, 01 Nov 2023 19:06:08 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273619 Archived-At: > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Wed, 01 Nov 2023 19:06:08 +0100 > > Eli Zaretskii 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.