From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 May 2023 15:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 63311 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 63311@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.168329937112891 (code B ref -1); Fri, 05 May 2023 15:10:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 May 2023 15:09:31 +0000 Received: from localhost ([127.0.0.1]:57253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pux3p-0003Lk-W1 for submit@debbugs.gnu.org; Fri, 05 May 2023 11:09:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:45464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pux3l-0003LY-Dv for submit@debbugs.gnu.org; Fri, 05 May 2023 11:09:28 -0400 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 1pux3l-0007wB-8R for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 11:09:25 -0400 Received: from ledu-giraud.fr ([51.159.28.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pux3h-0007pg-H7 for bug-gnu-emacs@gnu.org; Fri, 05 May 2023 11:09:25 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=AfeXw1q/ JOIEcjJ9DuxJHQJ1tlkfe93aGWYxcvEioeg=; h=date:subject:to:from; d=ledu-giraud.fr; b=M/9PkJbF2dkkukgFBUrIP1SuAMOJSQV62v5hawxilWkn9xYpqY bZuSNvMrqJsqZ2wcXnlSpxGzGv8BIGsjD9Cw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=AfeXw1q/JOIEcjJ9 DuxJHQJ1tlkfe93aGWYxcvEioeg=; h=date:subject:to:from; d=ledu-giraud.fr; b=ntRD5YdVDoSjwa/8BtCmr3KQBhoK30HkciCzsjfuXcn2Ls2PQD vuCgUbdh4EvFcfUi6izJP6hbhisAT+kZhp7rCDXQngrEigK9c1UH9BWjfjE1ZO06doQBcV MLCCLWJ9WPH2bVyo4tEp4JPfNKgSsrGp/OHak4mvoWe5ZQ8cHDGzNFf90B1zy7/50yN0lo OvlvKPR3Uy5VM+lPtXTrHLw6hd9B3dx9Zp/TQf/jBW59GjrsgavJr5mmHTdjOxpB74iY0i o1ewd6X3AGjv0xTfjF/okuUB/lfF8kv08Gmv5r0fr3M+Rhtjcld0P7cUtkY/wepRIUgE/Y 9TBz0XR5fZHw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id ba6276bf (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 5 May 2023 17:09:17 +0200 (CEST) From: Manuel Giraud Date: Fri, 05 May 2023 15:13:32 +0200 Message-ID: <87jzxmsyyr.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=51.159.28.247; envelope-from=manuel@ledu-giraud.fr; helo=ledu-giraud.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm trying to make sending mail over SMTP asynchronous. For this, I'm working on 'smtpmail-send-it'=E2=80=A6 but I think that that function does = too much and is hard to reason about. This patch just splits 'smtpmail-send-it' work into three functions: prepare a mail and queue it or send it. There should be no change in functionality (it is mostly code refactoring). I've tested it a bit with sending and queueing and this seems to work correctly but this needs way more eyes and tests. BTW, does anyone know the purpose of 'errbuf': I see it is created then erased and then killed? --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-smtpmail-send-it-split.patch >From 6481038443deae8bf4e309a641f5ce77717be712 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Fri, 5 May 2023 14:35:01 +0200 Subject: [PATCH] smtpmail-send-it split * lisp/mail/smtpmail.el (smtpmail-prepare-mail): New function that prepares the mail with current buffer content. (smtpmail-queue-mail): New function to queue a mail (prepared by 'smtpmail-prepare-mail'). (smtpmail-send-mail): New function to send a mail (prepared by 'smtpmail-send-mail'). (smtpmail-send-it): Use all three previous functions. --- lisp/mail/smtpmail.el | 407 +++++++++++++++++++++--------------------- 1 file changed, 206 insertions(+), 201 deletions(-) diff --git a/lisp/mail/smtpmail.el b/lisp/mail/smtpmail.el index 78688d170cc..7c61ca29de6 100644 --- a/lisp/mail/smtpmail.el +++ b/lisp/mail/smtpmail.el @@ -205,214 +205,219 @@ smtpmail-mail-address "Value to use for envelope-from address for mail from ambient buffer.") ;;; Functions +(defun smtpmail-prepare-mail (tembuf errbuf smtpmail-code-conv-from) + (let ((case-fold-search nil) + delimline + (mailbuf (current-buffer)) + ;; Examine this variable now, so that + ;; local binding in the mail buffer will take effect. + (smtpmail-mail-address + (save-restriction + ;; Only look at the headers when fetching the + ;; envelope address. + (message-narrow-to-headers) + (or (and mail-specify-envelope-from (mail-envelope-from)) + (let ((from (mail-fetch-field "from"))) + (and from + (cadr (mail-extract-address-components from)))) + (smtpmail-user-mail-address))))) + (with-current-buffer tembuf + (erase-buffer) + ;; Use the same `buffer-file-coding-system' as in the mail + ;; buffer, otherwise any `write-region' invocations (e.g., in + ;; mail-do-fcc below) will annoy with asking for a suitable + ;; encoding. + (set-buffer-file-coding-system smtpmail-code-conv-from nil t) + (insert-buffer-substring mailbuf) + (goto-char (point-max)) + ;; require one newline at the end. + (or (= (preceding-char) ?\n) + (insert ?\n)) + ;; Change header-delimiter to be what sendmail expects. + (mail-sendmail-undelimit-header) + (setq delimline (point-marker)) + (if mail-aliases + (expand-mail-aliases (point-min) delimline)) + (goto-char (point-min)) + ;; ignore any blank lines in the header + (while (and (re-search-forward "\n\n\n*" delimline t) + (< (point) delimline)) + (replace-match "\n")) + (let ((case-fold-search t)) + ;; We used to process Resent-... headers here, + ;; but it was not done properly, and the job + ;; is done correctly in `smtpmail-deduce-address-list'. + ;; Don't send out a blank subject line + (goto-char (point-min)) + (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) + (replace-match "") + ;; This one matches a Subject just before the header delimiter. + (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) + (= (match-end 0) delimline)) + (replace-match ""))) + ;; Put the "From:" field in unless for some odd reason + ;; they put one in themselves. + (goto-char (point-min)) + (if (not (re-search-forward "^From:" delimline t)) + (let* ((login smtpmail-mail-address) + (fullname (user-full-name))) + (cond ((eq mail-from-style 'angles) + (insert "From: " fullname) + (let ((fullname-start (+ (point-min) 6)) + (fullname-end (point-marker))) + (goto-char fullname-start) + ;; Look for a character that cannot appear unquoted + ;; according to RFC 822 or its successors. + (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" + fullname-end 1) + (progn + ;; Quote fullname, escaping specials. + (goto-char fullname-start) + (insert "\"") + (while (re-search-forward "[\"\\]" + fullname-end 1) + (replace-match "\\\\\\&" t)) + (insert "\"")))) + (insert " <" login ">\n")) + ((eq mail-from-style 'parens) + (insert "From: " login " (") + (let ((fullname-start (point))) + (insert fullname) + (let ((fullname-end (point-marker))) + (goto-char fullname-start) + ;; RFC 822 and its successors say \ and + ;; nonmatching parentheses must be + ;; escaped in comments. + ;; Escape every instance of ()\ ... + (while (re-search-forward "[()\\]" fullname-end 1) + (replace-match "\\\\\\&" t)) + ;; ... then undo escaping of matching parentheses, + ;; including matching nested parentheses. + (goto-char fullname-start) + (while (re-search-forward + "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" + fullname-end 1) + (replace-match "\\1(\\3)" t) + (goto-char fullname-start)))) + (insert ")\n")) + ((null mail-from-style) + (insert "From: " login "\n"))))) + ;; Insert a `Message-Id:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Message-Id:" delimline t) + (insert "Message-Id: " (message-make-message-id) "\n")) + ;; Insert a `Date:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Date:" delimline t) + (insert "Date: " (message-make-date) "\n")) + ;; Possibly add a MIME header for the current coding system + (let (charset) + (goto-char (point-min)) + (and (eq mail-send-nonascii 'mime) + (not (re-search-forward "^MIME-version:" delimline t)) + (progn (skip-chars-forward "\0-\177") + (/= (point) (point-max))) + smtpmail-code-conv-from + (setq charset + (coding-system-get smtpmail-code-conv-from + 'mime-charset)) + (goto-char delimline) + (insert "MIME-version: 1.0\n" + "Content-type: text/plain; charset=" + (symbol-name charset) + "\nContent-Transfer-Encoding: 8bit\n"))) + ;; Insert an extra newline if we need it to work around + ;; Sun's bug that swallows newlines. + (goto-char (1+ delimline)) + ;; Find and handle any Fcc fields. + (goto-char (point-min)) + (if (re-search-forward "^Fcc:" delimline t) + ;; Force `mail-do-fcc' to use the encoding of the mail + ;; buffer to encode outgoing messages on Fcc files. + (let ((coding-system-for-write + ;; mbox files must have Unix EOLs. + (coding-system-change-eol-conversion + smtpmail-code-conv-from 'unix))) + (mail-do-fcc delimline))) + (if mail-interactive + (with-current-buffer errbuf + (erase-buffer)))) + ;; Encode the header according to RFC2047. + (mail-encode-header (point-min) delimline) + ;; + (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) + (setq smtpmail-recipient-address-list + (smtpmail-deduce-address-list tembuf (point-min) delimline)) + (kill-buffer smtpmail-address-buffer) + + (smtpmail-do-bcc delimline)))) + +(defun smtpmail-queue-mail (tembuf smtpmail-code-conv-from) + (let* ((file-data + (expand-file-name + (format "%s_%i" + (format-time-string "%Y-%m-%d_%H:%M:%S") + (setq smtpmail-queue-counter + (1+ smtpmail-queue-counter))) + smtpmail-queue-dir)) + (file-data (convert-standard-filename file-data)) + (file-elisp (concat file-data ".el")) + (buffer-data (create-file-buffer file-data))) + (unless (file-exists-p smtpmail-queue-dir) + (make-directory smtpmail-queue-dir t)) + (with-current-buffer buffer-data + (erase-buffer) + (set-buffer-file-coding-system + ;; We will be reading the file with no-conversion in + ;; smtpmail-send-queued-mail below, so write it out + ;; with Unix EOLs. + (coding-system-change-eol-conversion + (or smtpmail-code-conv-from 'undecided) + 'unix) + nil t) + (insert-buffer-substring tembuf) + (write-file file-data) + (let ((coding-system-for-write 'utf-8)) + (with-temp-buffer + (insert "(setq ") + (dolist (var (cons 'smtpmail-recipient-address-list + ;; Perhaps store the server etc. + (and smtpmail-store-queue-variables + smtpmail--stored-queue-variables))) + (insert (format " %s %S\n" var (symbol-value var)))) + (insert ")\n") + (write-region (point-min) (point-max) file-elisp + nil 'silent))) + (write-region (concat file-data "\n") nil + (expand-file-name smtpmail-queue-index-file + smtpmail-queue-dir) + t 'silent)) + (kill-buffer buffer-data))) + +(defun smtpmail-send-mail (tembuf) + (if (not (null smtpmail-recipient-address-list)) + (when (setq result + (smtpmail-via-smtp + smtpmail-recipient-address-list tembuf)) + (error "Sending failed: %s" + (smtpmail--sanitize-error-message result))) + (error "Sending failed; no recipients"))) ;;;###autoload (defun smtpmail-send-it () (let ((errbuf (if mail-interactive (generate-new-buffer " smtpmail errors") 0)) - (tembuf (generate-new-buffer " smtpmail temp")) - (case-fold-search nil) - delimline - result - (mailbuf (current-buffer)) - ;; Examine this variable now, so that - ;; local binding in the mail buffer will take effect. - (smtpmail-mail-address - (save-restriction - ;; Only look at the headers when fetching the - ;; envelope address. - (message-narrow-to-headers) - (or (and mail-specify-envelope-from (mail-envelope-from)) - (let ((from (mail-fetch-field "from"))) - (and from - (cadr (mail-extract-address-components from)))) - (smtpmail-user-mail-address)))) - (smtpmail-code-conv-from - (if enable-multibyte-characters - (let ((sendmail-coding-system smtpmail-code-conv-from)) - (select-message-coding-system))))) + (tembuf (generate-new-buffer " smtpmail temp"))) (unwind-protect - (with-current-buffer tembuf - (erase-buffer) - ;; Use the same `buffer-file-coding-system' as in the mail - ;; buffer, otherwise any `write-region' invocations (e.g., in - ;; mail-do-fcc below) will annoy with asking for a suitable - ;; encoding. - (set-buffer-file-coding-system smtpmail-code-conv-from nil t) - (insert-buffer-substring mailbuf) - (goto-char (point-max)) - ;; require one newline at the end. - (or (= (preceding-char) ?\n) - (insert ?\n)) - ;; Change header-delimiter to be what sendmail expects. - (mail-sendmail-undelimit-header) - (setq delimline (point-marker)) - ;; (sendmail-synch-aliases) - (if mail-aliases - (expand-mail-aliases (point-min) delimline)) - (goto-char (point-min)) - ;; ignore any blank lines in the header - (while (and (re-search-forward "\n\n\n*" delimline t) - (< (point) delimline)) - (replace-match "\n")) - (let ((case-fold-search t)) - ;; We used to process Resent-... headers here, - ;; but it was not done properly, and the job - ;; is done correctly in `smtpmail-deduce-address-list'. - ;; Don't send out a blank subject line - (goto-char (point-min)) - (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) - (replace-match "") - ;; This one matches a Subject just before the header delimiter. - (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) - (= (match-end 0) delimline)) - (replace-match ""))) - ;; Put the "From:" field in unless for some odd reason - ;; they put one in themselves. - (goto-char (point-min)) - (if (not (re-search-forward "^From:" delimline t)) - (let* ((login smtpmail-mail-address) - (fullname (user-full-name))) - (cond ((eq mail-from-style 'angles) - (insert "From: " fullname) - (let ((fullname-start (+ (point-min) 6)) - (fullname-end (point-marker))) - (goto-char fullname-start) - ;; Look for a character that cannot appear unquoted - ;; according to RFC 822 or its successors. - (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" - fullname-end 1) - (progn - ;; Quote fullname, escaping specials. - (goto-char fullname-start) - (insert "\"") - (while (re-search-forward "[\"\\]" - fullname-end 1) - (replace-match "\\\\\\&" t)) - (insert "\"")))) - (insert " <" login ">\n")) - ((eq mail-from-style 'parens) - (insert "From: " login " (") - (let ((fullname-start (point))) - (insert fullname) - (let ((fullname-end (point-marker))) - (goto-char fullname-start) - ;; RFC 822 and its successors say \ and - ;; nonmatching parentheses must be - ;; escaped in comments. - ;; Escape every instance of ()\ ... - (while (re-search-forward "[()\\]" fullname-end 1) - (replace-match "\\\\\\&" t)) - ;; ... then undo escaping of matching parentheses, - ;; including matching nested parentheses. - (goto-char fullname-start) - (while (re-search-forward - "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" - fullname-end 1) - (replace-match "\\1(\\3)" t) - (goto-char fullname-start)))) - (insert ")\n")) - ((null mail-from-style) - (insert "From: " login "\n"))))) - ;; Insert a `Message-Id:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Message-Id:" delimline t) - (insert "Message-Id: " (message-make-message-id) "\n")) - ;; Insert a `Date:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Date:" delimline t) - (insert "Date: " (message-make-date) "\n")) - ;; Possibly add a MIME header for the current coding system - (let (charset) - (goto-char (point-min)) - (and (eq mail-send-nonascii 'mime) - (not (re-search-forward "^MIME-version:" delimline t)) - (progn (skip-chars-forward "\0-\177") - (/= (point) (point-max))) - smtpmail-code-conv-from - (setq charset - (coding-system-get smtpmail-code-conv-from - 'mime-charset)) - (goto-char delimline) - (insert "MIME-version: 1.0\n" - "Content-type: text/plain; charset=" - (symbol-name charset) - "\nContent-Transfer-Encoding: 8bit\n"))) - ;; Insert an extra newline if we need it to work around - ;; Sun's bug that swallows newlines. - (goto-char (1+ delimline)) - ;; Find and handle any Fcc fields. - (goto-char (point-min)) - (if (re-search-forward "^Fcc:" delimline t) - ;; Force `mail-do-fcc' to use the encoding of the mail - ;; buffer to encode outgoing messages on Fcc files. - (let ((coding-system-for-write - ;; mbox files must have Unix EOLs. - (coding-system-change-eol-conversion - smtpmail-code-conv-from 'unix))) - (mail-do-fcc delimline))) - (if mail-interactive - (with-current-buffer errbuf - (erase-buffer)))) - ;; Encode the header according to RFC2047. - (mail-encode-header (point-min) delimline) - ;; - (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) - (setq smtpmail-recipient-address-list - (smtpmail-deduce-address-list tembuf (point-min) delimline)) - (kill-buffer smtpmail-address-buffer) - - (smtpmail-do-bcc delimline) - ;; Send or queue - (if (not smtpmail-queue-mail) - (if (not (null smtpmail-recipient-address-list)) - (when (setq result - (smtpmail-via-smtp - smtpmail-recipient-address-list tembuf)) - (error "Sending failed: %s" - (smtpmail--sanitize-error-message result))) - (error "Sending failed; no recipients")) - (let* ((file-data - (expand-file-name - (format "%s_%i" - (format-time-string "%Y-%m-%d_%H:%M:%S") - (setq smtpmail-queue-counter - (1+ smtpmail-queue-counter))) - smtpmail-queue-dir)) - (file-data (convert-standard-filename file-data)) - (file-elisp (concat file-data ".el")) - (buffer-data (create-file-buffer file-data))) - (unless (file-exists-p smtpmail-queue-dir) - (make-directory smtpmail-queue-dir t)) - (with-current-buffer buffer-data - (erase-buffer) - (set-buffer-file-coding-system - ;; We will be reading the file with no-conversion in - ;; smtpmail-send-queued-mail below, so write it out - ;; with Unix EOLs. - (coding-system-change-eol-conversion - (or smtpmail-code-conv-from 'undecided) - 'unix) - nil t) - (insert-buffer-substring tembuf) - (write-file file-data) - (let ((coding-system-for-write 'utf-8)) - (with-temp-buffer - (insert "(setq ") - (dolist (var (cons 'smtpmail-recipient-address-list - ;; Perhaps store the server etc. - (and smtpmail-store-queue-variables - smtpmail--stored-queue-variables))) - (insert (format " %s %S\n" var (symbol-value var)))) - (insert ")\n") - (write-region (point-min) (point-max) file-elisp - nil 'silent))) - (write-region (concat file-data "\n") nil - (expand-file-name smtpmail-queue-index-file - smtpmail-queue-dir) - t 'silent)) - (kill-buffer buffer-data)))) + (let ((smtpmail-code-conv-from + (if enable-multibyte-characters + (let ((sendmail-coding-system smtpmail-code-conv-from)) + (select-message-coding-system))))) + (smtpmail-prepare-mail tembuf errbuf smtpmail-code-conv-from) + (if smtpmail-queue-mail + (smtpmail-queue-mail tembuf smtpmail-code-conv-from) + (smtpmail-send-mail tembuf))) (kill-buffer tembuf) (if (bufferp errbuf) (kill-buffer errbuf))))) -- 2.40.0 --=-=-= Content-Type: text/plain In GNU Emacs 30.0.50 (build 1, x86_64-unknown-openbsd7.3, cairo version 1.17.8) of 2023-05-05 built on computer Repository revision: f204c4a6cfa77fdbb2573b728110576e206b0b20 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101006 System Description: OpenBSD computer 7.3 GENERIC.MP#1125 amd64 Configured using: 'configure --prefix=/home/manuel/emacs --bindir=/home/manuel/bin --with-x-toolkit=no --without-sound --without-compress-install CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBXML2 MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM ZLIB Important settings: value of $LC_ALL: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Magit Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t display-time-mode: t display-battery-mode: t server-mode: t shell-dirtrack-mode: t override-global-mode: t repeat-mode: t desktop-save-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/manuel/.emacs.d/elpa/ef-themes-0.11.0/theme-loaddefs hides /home/manuel/emacs/share/emacs/30.0.50/lisp/theme-loaddefs /home/manuel/.emacs.d/elpa/transient-0.3.7/transient hides /home/manuel/emacs/share/emacs/30.0.50/lisp/transient Features: (shadow goto-addr dabbrev emacsbug whitespace magit-patch misearch multi-isearch magit-extras face-remap magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff git-commit log-edit add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor magit-mode transient magit-git magit-section magit-utils dash shr-color gnus-cite gnus-async gnus-bcklg gnus-ml gnus-topic mm-archive url-cache qp utf-7 imap rfc2104 nndoc nndraft nnmh nnfolder nnml gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache nnrss mm-url network-stream mailalias textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check sort mail-extr pulse tabify cus-edit cus-start cl-print smtpmail help-fns radix-tree vc-bzr vc-src vc-sccs vc-cvs vc-rcs log-view pcvs-util sh-script smie treesit executable vc-hg conf-mode view pascal vc mule-util hi-lock autorevert filenotify vc-git diff-mode vc-dispatcher vc-svn bug-reference paredit gnus-dired time battery cus-load exwm-randr xcb-randr exwm-config ido exwm exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types xcb-debug server modus-operandi-theme modus-themes zone speed-type url-http url-auth url-gw nsm compat ytdious mingus libmpdee reporter edebug debug backtrace transmission color calc-bin calc-ext calc calc-loaddefs rect calc-macs supercite regi ebdb-message ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range message sendmail yank-media puny rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums gmm-utils mailheader gnus-win gnus nnheader gnus-util mail-utils range mm-util mail-prsvr wid-edit ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev eieio-opt speedbar ezimage dframe find-func eieio-base pcase timezone visual-basic-mode cl web-mode derived disp-table erlang-start smart-tabs-mode skeleton cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs slime-asdf grep slime-tramp tramp rx tramp-loaddefs trampver tramp-integration files-x tramp-compat xdg shell pcomplete parse-time iso8601 time-date ls-lisp format-spec slime-fancy slime-indentation slime-cl-indent cl-indent slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references slime-compiler-notes-tree advice slime-scratch slime-presentations bridge slime-macrostep macrostep slime-mdot-fu slime-enclosing-context slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc slime-repl slime-parse slime apropos compile text-property-search etags fileloop generator xref project arc-mode archive-mode noutline outline icons pp comint ansi-osc ansi-color ring hyperspec thingatpt slime-autoloads edmacro kmacro use-package-bind-key bind-key appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs dired-x dired-aux dired dired-loaddefs notifications dbus xml cl-extra help-mode use-package-core repeat easy-mmode desktop frameset rust-mode-autoloads speed-type-autoloads osm-autoloads ebdb-autoloads compat-autoloads magit-autoloads debbugs-autoloads git-commit-autoloads magit-section-autoloads ef-themes-autoloads with-editor-autoloads paredit-autoloads dash-autoloads ytdious-autoloads transmission-autoloads transient-autoloads exwm-autoloads hyperbole-autoloads detached-autoloads info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind kqueue lcms2 dynamic-setting system-font-setting font-render-setting cairo xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 933133 308956) (symbols 48 55180 35) (strings 32 272198 12320) (string-bytes 1 8555283) (vectors 16 173055) (vector-slots 8 2925695 155806) (floats 8 544 5262) (intervals 56 18111 2469) (buffers 984 113)) -- Manuel Giraud --=-=-=-- From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 May 2023 18:57:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168331300915680 (code B ref 63311); Fri, 05 May 2023 18:57:02 +0000 Received: (at 63311) by debbugs.gnu.org; 5 May 2023 18:56:49 +0000 Received: from localhost ([127.0.0.1]:57559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pv0bo-00044q-UD for submit@debbugs.gnu.org; Fri, 05 May 2023 14:56:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pv0bj-00044Z-OA for 63311@debbugs.gnu.org; Fri, 05 May 2023 14:56:47 -0400 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 1pv0be-0003y7-3H; Fri, 05 May 2023 14:56:38 -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=3bZAxrR+JSC6NS0Q9HIN+TeqtywoqMZDvu1H3utTcZU=; b=OpK4qd19J/C3 aLr8Sh6OqwG1CANd/H0dMJQF1Mh1B+Ml9tjFMmykTDY0Qr0ZEcZoV/m520v/871AHbBQJlpAh7OJ8 UD384xQWFXFS9Yow3N6DrqgAmEuoWoR2XuuR64qLYApdKZy87twNFSS2VqkXSkXgittJUsdvYsD27 YzrHr1In7y5lJs3moKUeJeYfbSGXMkXAkxJTSg1o51UgTkamDgavbTJXzRW4VyWe+5JjPxibv9oBU 3oQm2+6ZyltSQAzL48z6gZH66xB4yh1HgSVUUrnElKT3PsML8nUzn4ZtEYF6BffSbQbmYu/DG5p2V ENIqEDM+SaIcKubPGEbaaQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pv0bc-00070o-OA; Fri, 05 May 2023 14:56:37 -0400 Date: Fri, 05 May 2023 21:57:29 +0300 Message-Id: <83ttwqhahy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87jzxmsyyr.fsf@ledu-giraud.fr> (bug-gnu-emacs@gnu.org) References: <87jzxmsyyr.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 05 May 2023 15:13:32 +0200 > From: Manuel Giraud via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > BTW, does anyone know the purpose of 'errbuf': I see it is created then > erased and then killed? Looks like a left-over from when this function was written. It is basically a rewrite of sendmail-send-it, which does use that variable. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 May 2023 06:20: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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16833539777491 (code B ref 63311); Sat, 06 May 2023 06:20:01 +0000 Received: (at 63311) by debbugs.gnu.org; 6 May 2023 06:19:37 +0000 Received: from localhost ([127.0.0.1]:58056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvBGb-0001wk-3b for submit@debbugs.gnu.org; Sat, 06 May 2023 02:19:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvBGY-0001wS-Me for 63311@debbugs.gnu.org; Sat, 06 May 2023 02:19:35 -0400 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 1pvBGT-0000nI-CK; Sat, 06 May 2023 02:19:29 -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=/p6mjfozqPsjPkL7lLpvhN8NZUdpVzsFTQ2e6YT17DI=; b=AZkV9mpT4Sio qqCw4np9QJxZP7iWU3huv8/Fr1YfxoODJVCUbGof+S8U4umD3rO7Ez5E3HlP70CqR2ESM07cJZ1Po H8khxX7bgreQvsqyoA7H0L6ZHhAgXteoY6GcBnLvnMDwdBygckKOumuTQylOy3hdjEQ1934lNqbec 7OXWd7cLQqFuMOFOfXnsx3A8/Sz4tWAr45OcsLVapExgdtXnCjWtypNY4n+Tm9Ye6qiOxL3oaBKp/ Cx126o1hfpKWl5ydQbX1iUnZi0Jk4cluSLshtDR4k1NtCCerc5tHtgUCk8bi+uvXyjxYco9PiYGPB QyyOsPNoORo4aMoi+imqoQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvBGT-0008Va-0S; Sat, 06 May 2023 02:19:29 -0400 Date: Sat, 06 May 2023 09:20:24 +0300 Message-Id: <83o7mygevr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <874joq34bk.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 05 May 2023 22:34:39 +0200) References: <87jzxmsyyr.fsf@ledu-giraud.fr> <83ttwqhahy.fsf@gnu.org> <874joq34bk.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Date: Fri, 05 May 2023 22:34:39 +0200 > > Eli Zaretskii writes: > > >> Date: Fri, 05 May 2023 15:13:32 +0200 > >> From: Manuel Giraud via "Bug reports for GNU Emacs, > >> the Swiss army knife of text editors" > >> > >> BTW, does anyone know the purpose of 'errbuf': I see it is created then > >> erased and then killed? > > > > Looks like a left-over from when this function was written. It is > > basically a rewrite of sendmail-send-it, which does use that variable. > > Ok. Do you want me to upgrade this patch removing errbuf? Sure, that's a good cleanup. (And please use Reply All, to have this discussion recorded by the tracker.) From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 May 2023 09:35: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168336566328719 (code B ref 63311); Sat, 06 May 2023 09:35:01 +0000 Received: (at 63311) by debbugs.gnu.org; 6 May 2023 09:34:23 +0000 Received: from localhost ([127.0.0.1]:59427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvEJ4-0007T8-HA for submit@debbugs.gnu.org; Sat, 06 May 2023 05:34:23 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:28751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvEIz-0007Sw-Lg for 63311@debbugs.gnu.org; Sat, 06 May 2023 05:34:21 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=IHbD4ji3 DET+oGd4yOMMqhh/IihYCvzJHmTqb42o92k=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=R73/n5egnWRrNleWm9LYlqgKz/XNkZ vJDl0kTFKfm8+c/NJhfthwnIygmsW+NOCYlL1L3otS4s/JSzqBZhTfBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=IHbD4ji3DET+oGd4 yOMMqhh/IihYCvzJHmTqb42o92k=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Bfagf6/wWFR6rJfub4BHEhX8GWnKNQ7Z/C4ked dOOlMbMg3GrC8Ps+6Ips9qb7vDf0N6NIjBjuOkIxZnSPU00u2xkMUN7tpTcwKfBS8P8fYe SkZJdkDWUTqP5iVy6NlwJC6Y8AUABDfQqzFCdBYb1zITW+pLOwYFBOkXd2ekI5YkIWbTWi sR5MhIbVXomMZ9MnY6IdbE5Fr9iQQIHp01h8PpAxD/n1v8SAY5Poqq/mPCZzBeU/pROEff TDKjir0t5jVnM5PPcVCmxk1+DJG3k0V/5VQPtnhCyHWQ5o1h5iSnGt1G0wjcs6WdZlhwQ2 jK1pfDlbbig3NDZX13nQldNg== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id c8a3e500 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 6 May 2023 11:34:15 +0200 (CEST) From: Manuel Giraud In-Reply-To: <83o7mygevr.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 May 2023 09:20:24 +0300") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <83ttwqhahy.fsf@gnu.org> <874joq34bk.fsf@ledu-giraud.fr> <83o7mygevr.fsf@gnu.org> Date: Sat, 06 May 2023 11:34:14 +0200 Message-ID: <87zg6h2489.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: [...] >> Ok. Do you want me to upgrade this patch removing errbuf? > > Sure, that's a good cleanup. Ok. Here is the modified patch. > (And please use Reply All, to have this discussion recorded by the > tracker.) Sure. Sorry about that. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-smtpmail-send-it-split.patch >From dfcaa8d0b9ec3fa0087326bb06dcdda5895f7142 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Fri, 5 May 2023 14:35:01 +0200 Subject: [PATCH] smtpmail-send-it split * lisp/mail/smtpmail.el (smtpmail-prepare-mail): New function that prepares the mail with current buffer content. (smtpmail-queue-mail): New function to queue a mail (prepared by 'smtpmail-prepare-mail'). (smtpmail-send-mail): New function to send a mail (prepared by 'smtpmail-send-mail'). (smtpmail-send-it): Use all three previous functions. While here, remove 'errbuf' leftovers. --- lisp/mail/smtpmail.el | 411 +++++++++++++++++++++--------------------- 1 file changed, 204 insertions(+), 207 deletions(-) diff --git a/lisp/mail/smtpmail.el b/lisp/mail/smtpmail.el index 78688d170cc..2c23e97afd0 100644 --- a/lisp/mail/smtpmail.el +++ b/lisp/mail/smtpmail.el @@ -205,217 +205,214 @@ smtpmail-mail-address "Value to use for envelope-from address for mail from ambient buffer.") ;;; Functions +(defun smtpmail-prepare-mail (tembuf smtpmail-code-conv-from) + (let ((case-fold-search nil) + delimline + (mailbuf (current-buffer)) + ;; Examine this variable now, so that + ;; local binding in the mail buffer will take effect. + (smtpmail-mail-address + (save-restriction + ;; Only look at the headers when fetching the + ;; envelope address. + (message-narrow-to-headers) + (or (and mail-specify-envelope-from (mail-envelope-from)) + (let ((from (mail-fetch-field "from"))) + (and from + (cadr (mail-extract-address-components from)))) + (smtpmail-user-mail-address))))) + (with-current-buffer tembuf + (erase-buffer) + ;; Use the same `buffer-file-coding-system' as in the mail + ;; buffer, otherwise any `write-region' invocations (e.g., in + ;; mail-do-fcc below) will annoy with asking for a suitable + ;; encoding. + (set-buffer-file-coding-system smtpmail-code-conv-from nil t) + (insert-buffer-substring mailbuf) + (goto-char (point-max)) + ;; require one newline at the end. + (or (= (preceding-char) ?\n) + (insert ?\n)) + ;; Change header-delimiter to be what sendmail expects. + (mail-sendmail-undelimit-header) + (setq delimline (point-marker)) + (if mail-aliases + (expand-mail-aliases (point-min) delimline)) + (goto-char (point-min)) + ;; ignore any blank lines in the header + (while (and (re-search-forward "\n\n\n*" delimline t) + (< (point) delimline)) + (replace-match "\n")) + (let ((case-fold-search t)) + ;; We used to process Resent-... headers here, + ;; but it was not done properly, and the job + ;; is done correctly in `smtpmail-deduce-address-list'. + ;; Don't send out a blank subject line + (goto-char (point-min)) + (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) + (replace-match "") + ;; This one matches a Subject just before the header delimiter. + (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) + (= (match-end 0) delimline)) + (replace-match ""))) + ;; Put the "From:" field in unless for some odd reason + ;; they put one in themselves. + (goto-char (point-min)) + (if (not (re-search-forward "^From:" delimline t)) + (let* ((login smtpmail-mail-address) + (fullname (user-full-name))) + (cond ((eq mail-from-style 'angles) + (insert "From: " fullname) + (let ((fullname-start (+ (point-min) 6)) + (fullname-end (point-marker))) + (goto-char fullname-start) + ;; Look for a character that cannot appear unquoted + ;; according to RFC 822 or its successors. + (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" + fullname-end 1) + (progn + ;; Quote fullname, escaping specials. + (goto-char fullname-start) + (insert "\"") + (while (re-search-forward "[\"\\]" + fullname-end 1) + (replace-match "\\\\\\&" t)) + (insert "\"")))) + (insert " <" login ">\n")) + ((eq mail-from-style 'parens) + (insert "From: " login " (") + (let ((fullname-start (point))) + (insert fullname) + (let ((fullname-end (point-marker))) + (goto-char fullname-start) + ;; RFC 822 and its successors say \ and + ;; nonmatching parentheses must be + ;; escaped in comments. + ;; Escape every instance of ()\ ... + (while (re-search-forward "[()\\]" fullname-end 1) + (replace-match "\\\\\\&" t)) + ;; ... then undo escaping of matching parentheses, + ;; including matching nested parentheses. + (goto-char fullname-start) + (while (re-search-forward + "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" + fullname-end 1) + (replace-match "\\1(\\3)" t) + (goto-char fullname-start)))) + (insert ")\n")) + ((null mail-from-style) + (insert "From: " login "\n"))))) + ;; Insert a `Message-Id:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Message-Id:" delimline t) + (insert "Message-Id: " (message-make-message-id) "\n")) + ;; Insert a `Date:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Date:" delimline t) + (insert "Date: " (message-make-date) "\n")) + ;; Possibly add a MIME header for the current coding system + (let (charset) + (goto-char (point-min)) + (and (eq mail-send-nonascii 'mime) + (not (re-search-forward "^MIME-version:" delimline t)) + (progn (skip-chars-forward "\0-\177") + (/= (point) (point-max))) + smtpmail-code-conv-from + (setq charset + (coding-system-get smtpmail-code-conv-from + 'mime-charset)) + (goto-char delimline) + (insert "MIME-version: 1.0\n" + "Content-type: text/plain; charset=" + (symbol-name charset) + "\nContent-Transfer-Encoding: 8bit\n"))) + ;; Insert an extra newline if we need it to work around + ;; Sun's bug that swallows newlines. + (goto-char (1+ delimline)) + ;; Find and handle any Fcc fields. + (goto-char (point-min)) + (if (re-search-forward "^Fcc:" delimline t) + ;; Force `mail-do-fcc' to use the encoding of the mail + ;; buffer to encode outgoing messages on Fcc files. + (let ((coding-system-for-write + ;; mbox files must have Unix EOLs. + (coding-system-change-eol-conversion + smtpmail-code-conv-from 'unix))) + (mail-do-fcc delimline)))) + ;; Encode the header according to RFC2047. + (mail-encode-header (point-min) delimline) + ;; + (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) + (setq smtpmail-recipient-address-list + (smtpmail-deduce-address-list tembuf (point-min) delimline)) + (kill-buffer smtpmail-address-buffer) + + (smtpmail-do-bcc delimline)))) + +(defun smtpmail-queue-mail (tembuf smtpmail-code-conv-from) + (let* ((file-data + (expand-file-name + (format "%s_%i" + (format-time-string "%Y-%m-%d_%H:%M:%S") + (setq smtpmail-queue-counter + (1+ smtpmail-queue-counter))) + smtpmail-queue-dir)) + (file-data (convert-standard-filename file-data)) + (file-elisp (concat file-data ".el")) + (buffer-data (create-file-buffer file-data))) + (unless (file-exists-p smtpmail-queue-dir) + (make-directory smtpmail-queue-dir t)) + (with-current-buffer buffer-data + (erase-buffer) + (set-buffer-file-coding-system + ;; We will be reading the file with no-conversion in + ;; smtpmail-send-queued-mail below, so write it out + ;; with Unix EOLs. + (coding-system-change-eol-conversion + (or smtpmail-code-conv-from 'undecided) + 'unix) + nil t) + (insert-buffer-substring tembuf) + (write-file file-data) + (let ((coding-system-for-write 'utf-8)) + (with-temp-buffer + (insert "(setq ") + (dolist (var (cons 'smtpmail-recipient-address-list + ;; Perhaps store the server etc. + (and smtpmail-store-queue-variables + smtpmail--stored-queue-variables))) + (insert (format " %s %S\n" var (symbol-value var)))) + (insert ")\n") + (write-region (point-min) (point-max) file-elisp + nil 'silent))) + (write-region (concat file-data "\n") nil + (expand-file-name smtpmail-queue-index-file + smtpmail-queue-dir) + t 'silent)) + (kill-buffer buffer-data))) + +(defun smtpmail-send-mail (tembuf) + (if (not (null smtpmail-recipient-address-list)) + (when (setq result + (smtpmail-via-smtp + smtpmail-recipient-address-list tembuf)) + (error "Sending failed: %s" + (smtpmail--sanitize-error-message result))) + (error "Sending failed; no recipients"))) ;;;###autoload (defun smtpmail-send-it () - (let ((errbuf (if mail-interactive - (generate-new-buffer " smtpmail errors") - 0)) - (tembuf (generate-new-buffer " smtpmail temp")) - (case-fold-search nil) - delimline - result - (mailbuf (current-buffer)) - ;; Examine this variable now, so that - ;; local binding in the mail buffer will take effect. - (smtpmail-mail-address - (save-restriction - ;; Only look at the headers when fetching the - ;; envelope address. - (message-narrow-to-headers) - (or (and mail-specify-envelope-from (mail-envelope-from)) - (let ((from (mail-fetch-field "from"))) - (and from - (cadr (mail-extract-address-components from)))) - (smtpmail-user-mail-address)))) - (smtpmail-code-conv-from - (if enable-multibyte-characters - (let ((sendmail-coding-system smtpmail-code-conv-from)) - (select-message-coding-system))))) + (let ((tembuf (generate-new-buffer " smtpmail temp"))) (unwind-protect - (with-current-buffer tembuf - (erase-buffer) - ;; Use the same `buffer-file-coding-system' as in the mail - ;; buffer, otherwise any `write-region' invocations (e.g., in - ;; mail-do-fcc below) will annoy with asking for a suitable - ;; encoding. - (set-buffer-file-coding-system smtpmail-code-conv-from nil t) - (insert-buffer-substring mailbuf) - (goto-char (point-max)) - ;; require one newline at the end. - (or (= (preceding-char) ?\n) - (insert ?\n)) - ;; Change header-delimiter to be what sendmail expects. - (mail-sendmail-undelimit-header) - (setq delimline (point-marker)) - ;; (sendmail-synch-aliases) - (if mail-aliases - (expand-mail-aliases (point-min) delimline)) - (goto-char (point-min)) - ;; ignore any blank lines in the header - (while (and (re-search-forward "\n\n\n*" delimline t) - (< (point) delimline)) - (replace-match "\n")) - (let ((case-fold-search t)) - ;; We used to process Resent-... headers here, - ;; but it was not done properly, and the job - ;; is done correctly in `smtpmail-deduce-address-list'. - ;; Don't send out a blank subject line - (goto-char (point-min)) - (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) - (replace-match "") - ;; This one matches a Subject just before the header delimiter. - (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) - (= (match-end 0) delimline)) - (replace-match ""))) - ;; Put the "From:" field in unless for some odd reason - ;; they put one in themselves. - (goto-char (point-min)) - (if (not (re-search-forward "^From:" delimline t)) - (let* ((login smtpmail-mail-address) - (fullname (user-full-name))) - (cond ((eq mail-from-style 'angles) - (insert "From: " fullname) - (let ((fullname-start (+ (point-min) 6)) - (fullname-end (point-marker))) - (goto-char fullname-start) - ;; Look for a character that cannot appear unquoted - ;; according to RFC 822 or its successors. - (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" - fullname-end 1) - (progn - ;; Quote fullname, escaping specials. - (goto-char fullname-start) - (insert "\"") - (while (re-search-forward "[\"\\]" - fullname-end 1) - (replace-match "\\\\\\&" t)) - (insert "\"")))) - (insert " <" login ">\n")) - ((eq mail-from-style 'parens) - (insert "From: " login " (") - (let ((fullname-start (point))) - (insert fullname) - (let ((fullname-end (point-marker))) - (goto-char fullname-start) - ;; RFC 822 and its successors say \ and - ;; nonmatching parentheses must be - ;; escaped in comments. - ;; Escape every instance of ()\ ... - (while (re-search-forward "[()\\]" fullname-end 1) - (replace-match "\\\\\\&" t)) - ;; ... then undo escaping of matching parentheses, - ;; including matching nested parentheses. - (goto-char fullname-start) - (while (re-search-forward - "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" - fullname-end 1) - (replace-match "\\1(\\3)" t) - (goto-char fullname-start)))) - (insert ")\n")) - ((null mail-from-style) - (insert "From: " login "\n"))))) - ;; Insert a `Message-Id:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Message-Id:" delimline t) - (insert "Message-Id: " (message-make-message-id) "\n")) - ;; Insert a `Date:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Date:" delimline t) - (insert "Date: " (message-make-date) "\n")) - ;; Possibly add a MIME header for the current coding system - (let (charset) - (goto-char (point-min)) - (and (eq mail-send-nonascii 'mime) - (not (re-search-forward "^MIME-version:" delimline t)) - (progn (skip-chars-forward "\0-\177") - (/= (point) (point-max))) - smtpmail-code-conv-from - (setq charset - (coding-system-get smtpmail-code-conv-from - 'mime-charset)) - (goto-char delimline) - (insert "MIME-version: 1.0\n" - "Content-type: text/plain; charset=" - (symbol-name charset) - "\nContent-Transfer-Encoding: 8bit\n"))) - ;; Insert an extra newline if we need it to work around - ;; Sun's bug that swallows newlines. - (goto-char (1+ delimline)) - ;; Find and handle any Fcc fields. - (goto-char (point-min)) - (if (re-search-forward "^Fcc:" delimline t) - ;; Force `mail-do-fcc' to use the encoding of the mail - ;; buffer to encode outgoing messages on Fcc files. - (let ((coding-system-for-write - ;; mbox files must have Unix EOLs. - (coding-system-change-eol-conversion - smtpmail-code-conv-from 'unix))) - (mail-do-fcc delimline))) - (if mail-interactive - (with-current-buffer errbuf - (erase-buffer)))) - ;; Encode the header according to RFC2047. - (mail-encode-header (point-min) delimline) - ;; - (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) - (setq smtpmail-recipient-address-list - (smtpmail-deduce-address-list tembuf (point-min) delimline)) - (kill-buffer smtpmail-address-buffer) - - (smtpmail-do-bcc delimline) - ;; Send or queue - (if (not smtpmail-queue-mail) - (if (not (null smtpmail-recipient-address-list)) - (when (setq result - (smtpmail-via-smtp - smtpmail-recipient-address-list tembuf)) - (error "Sending failed: %s" - (smtpmail--sanitize-error-message result))) - (error "Sending failed; no recipients")) - (let* ((file-data - (expand-file-name - (format "%s_%i" - (format-time-string "%Y-%m-%d_%H:%M:%S") - (setq smtpmail-queue-counter - (1+ smtpmail-queue-counter))) - smtpmail-queue-dir)) - (file-data (convert-standard-filename file-data)) - (file-elisp (concat file-data ".el")) - (buffer-data (create-file-buffer file-data))) - (unless (file-exists-p smtpmail-queue-dir) - (make-directory smtpmail-queue-dir t)) - (with-current-buffer buffer-data - (erase-buffer) - (set-buffer-file-coding-system - ;; We will be reading the file with no-conversion in - ;; smtpmail-send-queued-mail below, so write it out - ;; with Unix EOLs. - (coding-system-change-eol-conversion - (or smtpmail-code-conv-from 'undecided) - 'unix) - nil t) - (insert-buffer-substring tembuf) - (write-file file-data) - (let ((coding-system-for-write 'utf-8)) - (with-temp-buffer - (insert "(setq ") - (dolist (var (cons 'smtpmail-recipient-address-list - ;; Perhaps store the server etc. - (and smtpmail-store-queue-variables - smtpmail--stored-queue-variables))) - (insert (format " %s %S\n" var (symbol-value var)))) - (insert ")\n") - (write-region (point-min) (point-max) file-elisp - nil 'silent))) - (write-region (concat file-data "\n") nil - (expand-file-name smtpmail-queue-index-file - smtpmail-queue-dir) - t 'silent)) - (kill-buffer buffer-data)))) - (kill-buffer tembuf) - (if (bufferp errbuf) - (kill-buffer errbuf))))) + (let ((smtpmail-code-conv-from + (if enable-multibyte-characters + (let ((sendmail-coding-system smtpmail-code-conv-from)) + (select-message-coding-system))))) + (smtpmail-prepare-mail tembuf smtpmail-code-conv-from) + (if smtpmail-queue-mail + (smtpmail-queue-mail tembuf smtpmail-code-conv-from) + (smtpmail-send-mail tembuf))) + (kill-buffer tembuf)))) ;;;###autoload (defun smtpmail-send-queued-mail () -- 2.40.0 --=-=-= Content-Type: text/plain -- Manuel Giraud --=-=-=-- From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 May 2023 09:54:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168362598322966 (code B ref 63311); Tue, 09 May 2023 09:54:02 +0000 Received: (at 63311) by debbugs.gnu.org; 9 May 2023 09:53:03 +0000 Received: from localhost ([127.0.0.1]:42448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwK1m-0005yB-0y for submit@debbugs.gnu.org; Tue, 09 May 2023 05:53:03 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:47396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwK1j-0005xu-3Q for 63311@debbugs.gnu.org; Tue, 09 May 2023 05:53:00 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=qI2V5tKd ylBtRXadS2wMZZO4QUxAItVwhZFO7pys6ms=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=AqdHC1Yp5dZRfU8/h9Psx7FBgSo7bt mQRElHC61Tz6ejU/Y1n97SAx09KCRLNQ1+bcZ25+Mt5CyofdTHyQd1Aw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=qI2V5tKdylBtRXad S2wMZZO4QUxAItVwhZFO7pys6ms=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=hc13BnzbFwJNGR8Ifrk32Wtp14A63NTNLHGwXx 7xbf+n0gZgvwhZY61sgHOOlJXAvWzrDTJijowkUUb/UHV0W+hkR+Gnqu4cu+BO9VIwAepm dBXtAObQ+Od9ylGb0NeC9c2XNXCJg2PlusEwZdbOKW0Gt/M23oJVHf3lPxmR20fNVPocAF 5xVSqZ1wtoKxeracd5Houn5rw2oUWUtQdSXRAUmlitPYE8L72LoaHp2jBd0cykSb0jZ9HO gQrbaaPBNtGUxiuRthC4j0xg/qXECA4et4hn/H3fXdK6vlHCIHGrbCrxeDy7t10JXpCYMk Ao1Sh+7R808t3m8ljXiwOXZQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id a88c1b56 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 9 May 2023 11:52:57 +0200 (CEST) From: Manuel Giraud In-Reply-To: <83o7mygevr.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 May 2023 09:20:24 +0300") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <83ttwqhahy.fsf@gnu.org> <874joq34bk.fsf@ledu-giraud.fr> <83o7mygevr.fsf@gnu.org> Date: Tue, 09 May 2023 11:52:56 +0200 Message-ID: <87wn1hzv9j.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hi, I forgot to "declare" 'result' in smtpmail-send-it. Here is an updated version. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-smtpmail-send-it-split.patch >From a7786a443abebe38acd968dcd7ea2c2f2364d4a0 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Fri, 5 May 2023 14:35:01 +0200 Subject: [PATCH] smtpmail-send-it split * lisp/mail/smtpmail.el (smtpmail-prepare-mail): New function that prepares the mail with current buffer content. (smtpmail-queue-mail): New function to queue a mail (prepared by 'smtpmail-prepare-mail'). (smtpmail-send-mail): New function to send a mail (prepared by 'smtpmail-send-mail'). (smtpmail-send-it): Use all three previous functions. While here, remove 'errbuf' leftovers. --- lisp/mail/smtpmail.el | 412 +++++++++++++++++++++--------------------- 1 file changed, 205 insertions(+), 207 deletions(-) diff --git a/lisp/mail/smtpmail.el b/lisp/mail/smtpmail.el index 78688d170cc..714f1e14eaf 100644 --- a/lisp/mail/smtpmail.el +++ b/lisp/mail/smtpmail.el @@ -205,217 +205,215 @@ smtpmail-mail-address "Value to use for envelope-from address for mail from ambient buffer.") ;;; Functions +(defun smtpmail-prepare-mail (tembuf smtpmail-code-conv-from) + (let ((case-fold-search nil) + delimline + (mailbuf (current-buffer)) + ;; Examine this variable now, so that + ;; local binding in the mail buffer will take effect. + (smtpmail-mail-address + (save-restriction + ;; Only look at the headers when fetching the + ;; envelope address. + (message-narrow-to-headers) + (or (and mail-specify-envelope-from (mail-envelope-from)) + (let ((from (mail-fetch-field "from"))) + (and from + (cadr (mail-extract-address-components from)))) + (smtpmail-user-mail-address))))) + (with-current-buffer tembuf + (erase-buffer) + ;; Use the same `buffer-file-coding-system' as in the mail + ;; buffer, otherwise any `write-region' invocations (e.g., in + ;; mail-do-fcc below) will annoy with asking for a suitable + ;; encoding. + (set-buffer-file-coding-system smtpmail-code-conv-from nil t) + (insert-buffer-substring mailbuf) + (goto-char (point-max)) + ;; require one newline at the end. + (or (= (preceding-char) ?\n) + (insert ?\n)) + ;; Change header-delimiter to be what sendmail expects. + (mail-sendmail-undelimit-header) + (setq delimline (point-marker)) + (if mail-aliases + (expand-mail-aliases (point-min) delimline)) + (goto-char (point-min)) + ;; ignore any blank lines in the header + (while (and (re-search-forward "\n\n\n*" delimline t) + (< (point) delimline)) + (replace-match "\n")) + (let ((case-fold-search t)) + ;; We used to process Resent-... headers here, + ;; but it was not done properly, and the job + ;; is done correctly in `smtpmail-deduce-address-list'. + ;; Don't send out a blank subject line + (goto-char (point-min)) + (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) + (replace-match "") + ;; This one matches a Subject just before the header delimiter. + (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) + (= (match-end 0) delimline)) + (replace-match ""))) + ;; Put the "From:" field in unless for some odd reason + ;; they put one in themselves. + (goto-char (point-min)) + (if (not (re-search-forward "^From:" delimline t)) + (let* ((login smtpmail-mail-address) + (fullname (user-full-name))) + (cond ((eq mail-from-style 'angles) + (insert "From: " fullname) + (let ((fullname-start (+ (point-min) 6)) + (fullname-end (point-marker))) + (goto-char fullname-start) + ;; Look for a character that cannot appear unquoted + ;; according to RFC 822 or its successors. + (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" + fullname-end 1) + (progn + ;; Quote fullname, escaping specials. + (goto-char fullname-start) + (insert "\"") + (while (re-search-forward "[\"\\]" + fullname-end 1) + (replace-match "\\\\\\&" t)) + (insert "\"")))) + (insert " <" login ">\n")) + ((eq mail-from-style 'parens) + (insert "From: " login " (") + (let ((fullname-start (point))) + (insert fullname) + (let ((fullname-end (point-marker))) + (goto-char fullname-start) + ;; RFC 822 and its successors say \ and + ;; nonmatching parentheses must be + ;; escaped in comments. + ;; Escape every instance of ()\ ... + (while (re-search-forward "[()\\]" fullname-end 1) + (replace-match "\\\\\\&" t)) + ;; ... then undo escaping of matching parentheses, + ;; including matching nested parentheses. + (goto-char fullname-start) + (while (re-search-forward + "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" + fullname-end 1) + (replace-match "\\1(\\3)" t) + (goto-char fullname-start)))) + (insert ")\n")) + ((null mail-from-style) + (insert "From: " login "\n"))))) + ;; Insert a `Message-Id:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Message-Id:" delimline t) + (insert "Message-Id: " (message-make-message-id) "\n")) + ;; Insert a `Date:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Date:" delimline t) + (insert "Date: " (message-make-date) "\n")) + ;; Possibly add a MIME header for the current coding system + (let (charset) + (goto-char (point-min)) + (and (eq mail-send-nonascii 'mime) + (not (re-search-forward "^MIME-version:" delimline t)) + (progn (skip-chars-forward "\0-\177") + (/= (point) (point-max))) + smtpmail-code-conv-from + (setq charset + (coding-system-get smtpmail-code-conv-from + 'mime-charset)) + (goto-char delimline) + (insert "MIME-version: 1.0\n" + "Content-type: text/plain; charset=" + (symbol-name charset) + "\nContent-Transfer-Encoding: 8bit\n"))) + ;; Insert an extra newline if we need it to work around + ;; Sun's bug that swallows newlines. + (goto-char (1+ delimline)) + ;; Find and handle any Fcc fields. + (goto-char (point-min)) + (if (re-search-forward "^Fcc:" delimline t) + ;; Force `mail-do-fcc' to use the encoding of the mail + ;; buffer to encode outgoing messages on Fcc files. + (let ((coding-system-for-write + ;; mbox files must have Unix EOLs. + (coding-system-change-eol-conversion + smtpmail-code-conv-from 'unix))) + (mail-do-fcc delimline)))) + ;; Encode the header according to RFC2047. + (mail-encode-header (point-min) delimline) + ;; + (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) + (setq smtpmail-recipient-address-list + (smtpmail-deduce-address-list tembuf (point-min) delimline)) + (kill-buffer smtpmail-address-buffer) + + (smtpmail-do-bcc delimline)))) + +(defun smtpmail-queue-mail (tembuf smtpmail-code-conv-from) + (let* ((file-data + (expand-file-name + (format "%s_%i" + (format-time-string "%Y-%m-%d_%H:%M:%S") + (setq smtpmail-queue-counter + (1+ smtpmail-queue-counter))) + smtpmail-queue-dir)) + (file-data (convert-standard-filename file-data)) + (file-elisp (concat file-data ".el")) + (buffer-data (create-file-buffer file-data))) + (unless (file-exists-p smtpmail-queue-dir) + (make-directory smtpmail-queue-dir t)) + (with-current-buffer buffer-data + (erase-buffer) + (set-buffer-file-coding-system + ;; We will be reading the file with no-conversion in + ;; smtpmail-send-queued-mail below, so write it out + ;; with Unix EOLs. + (coding-system-change-eol-conversion + (or smtpmail-code-conv-from 'undecided) + 'unix) + nil t) + (insert-buffer-substring tembuf) + (write-file file-data) + (let ((coding-system-for-write 'utf-8)) + (with-temp-buffer + (insert "(setq ") + (dolist (var (cons 'smtpmail-recipient-address-list + ;; Perhaps store the server etc. + (and smtpmail-store-queue-variables + smtpmail--stored-queue-variables))) + (insert (format " %s %S\n" var (symbol-value var)))) + (insert ")\n") + (write-region (point-min) (point-max) file-elisp + nil 'silent))) + (write-region (concat file-data "\n") nil + (expand-file-name smtpmail-queue-index-file + smtpmail-queue-dir) + t 'silent)) + (kill-buffer buffer-data))) + +(defun smtpmail-send-mail (tembuf) + (let (result) + (if (not (null smtpmail-recipient-address-list)) + (when (setq result + (smtpmail-via-smtp + smtpmail-recipient-address-list tembuf)) + (error "Sending failed: %s" + (smtpmail--sanitize-error-message result))) + (error "Sending failed; no recipients")))) ;;;###autoload (defun smtpmail-send-it () - (let ((errbuf (if mail-interactive - (generate-new-buffer " smtpmail errors") - 0)) - (tembuf (generate-new-buffer " smtpmail temp")) - (case-fold-search nil) - delimline - result - (mailbuf (current-buffer)) - ;; Examine this variable now, so that - ;; local binding in the mail buffer will take effect. - (smtpmail-mail-address - (save-restriction - ;; Only look at the headers when fetching the - ;; envelope address. - (message-narrow-to-headers) - (or (and mail-specify-envelope-from (mail-envelope-from)) - (let ((from (mail-fetch-field "from"))) - (and from - (cadr (mail-extract-address-components from)))) - (smtpmail-user-mail-address)))) - (smtpmail-code-conv-from - (if enable-multibyte-characters - (let ((sendmail-coding-system smtpmail-code-conv-from)) - (select-message-coding-system))))) + (let ((tembuf (generate-new-buffer " smtpmail temp"))) (unwind-protect - (with-current-buffer tembuf - (erase-buffer) - ;; Use the same `buffer-file-coding-system' as in the mail - ;; buffer, otherwise any `write-region' invocations (e.g., in - ;; mail-do-fcc below) will annoy with asking for a suitable - ;; encoding. - (set-buffer-file-coding-system smtpmail-code-conv-from nil t) - (insert-buffer-substring mailbuf) - (goto-char (point-max)) - ;; require one newline at the end. - (or (= (preceding-char) ?\n) - (insert ?\n)) - ;; Change header-delimiter to be what sendmail expects. - (mail-sendmail-undelimit-header) - (setq delimline (point-marker)) - ;; (sendmail-synch-aliases) - (if mail-aliases - (expand-mail-aliases (point-min) delimline)) - (goto-char (point-min)) - ;; ignore any blank lines in the header - (while (and (re-search-forward "\n\n\n*" delimline t) - (< (point) delimline)) - (replace-match "\n")) - (let ((case-fold-search t)) - ;; We used to process Resent-... headers here, - ;; but it was not done properly, and the job - ;; is done correctly in `smtpmail-deduce-address-list'. - ;; Don't send out a blank subject line - (goto-char (point-min)) - (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) - (replace-match "") - ;; This one matches a Subject just before the header delimiter. - (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) - (= (match-end 0) delimline)) - (replace-match ""))) - ;; Put the "From:" field in unless for some odd reason - ;; they put one in themselves. - (goto-char (point-min)) - (if (not (re-search-forward "^From:" delimline t)) - (let* ((login smtpmail-mail-address) - (fullname (user-full-name))) - (cond ((eq mail-from-style 'angles) - (insert "From: " fullname) - (let ((fullname-start (+ (point-min) 6)) - (fullname-end (point-marker))) - (goto-char fullname-start) - ;; Look for a character that cannot appear unquoted - ;; according to RFC 822 or its successors. - (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" - fullname-end 1) - (progn - ;; Quote fullname, escaping specials. - (goto-char fullname-start) - (insert "\"") - (while (re-search-forward "[\"\\]" - fullname-end 1) - (replace-match "\\\\\\&" t)) - (insert "\"")))) - (insert " <" login ">\n")) - ((eq mail-from-style 'parens) - (insert "From: " login " (") - (let ((fullname-start (point))) - (insert fullname) - (let ((fullname-end (point-marker))) - (goto-char fullname-start) - ;; RFC 822 and its successors say \ and - ;; nonmatching parentheses must be - ;; escaped in comments. - ;; Escape every instance of ()\ ... - (while (re-search-forward "[()\\]" fullname-end 1) - (replace-match "\\\\\\&" t)) - ;; ... then undo escaping of matching parentheses, - ;; including matching nested parentheses. - (goto-char fullname-start) - (while (re-search-forward - "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" - fullname-end 1) - (replace-match "\\1(\\3)" t) - (goto-char fullname-start)))) - (insert ")\n")) - ((null mail-from-style) - (insert "From: " login "\n"))))) - ;; Insert a `Message-Id:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Message-Id:" delimline t) - (insert "Message-Id: " (message-make-message-id) "\n")) - ;; Insert a `Date:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Date:" delimline t) - (insert "Date: " (message-make-date) "\n")) - ;; Possibly add a MIME header for the current coding system - (let (charset) - (goto-char (point-min)) - (and (eq mail-send-nonascii 'mime) - (not (re-search-forward "^MIME-version:" delimline t)) - (progn (skip-chars-forward "\0-\177") - (/= (point) (point-max))) - smtpmail-code-conv-from - (setq charset - (coding-system-get smtpmail-code-conv-from - 'mime-charset)) - (goto-char delimline) - (insert "MIME-version: 1.0\n" - "Content-type: text/plain; charset=" - (symbol-name charset) - "\nContent-Transfer-Encoding: 8bit\n"))) - ;; Insert an extra newline if we need it to work around - ;; Sun's bug that swallows newlines. - (goto-char (1+ delimline)) - ;; Find and handle any Fcc fields. - (goto-char (point-min)) - (if (re-search-forward "^Fcc:" delimline t) - ;; Force `mail-do-fcc' to use the encoding of the mail - ;; buffer to encode outgoing messages on Fcc files. - (let ((coding-system-for-write - ;; mbox files must have Unix EOLs. - (coding-system-change-eol-conversion - smtpmail-code-conv-from 'unix))) - (mail-do-fcc delimline))) - (if mail-interactive - (with-current-buffer errbuf - (erase-buffer)))) - ;; Encode the header according to RFC2047. - (mail-encode-header (point-min) delimline) - ;; - (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) - (setq smtpmail-recipient-address-list - (smtpmail-deduce-address-list tembuf (point-min) delimline)) - (kill-buffer smtpmail-address-buffer) - - (smtpmail-do-bcc delimline) - ;; Send or queue - (if (not smtpmail-queue-mail) - (if (not (null smtpmail-recipient-address-list)) - (when (setq result - (smtpmail-via-smtp - smtpmail-recipient-address-list tembuf)) - (error "Sending failed: %s" - (smtpmail--sanitize-error-message result))) - (error "Sending failed; no recipients")) - (let* ((file-data - (expand-file-name - (format "%s_%i" - (format-time-string "%Y-%m-%d_%H:%M:%S") - (setq smtpmail-queue-counter - (1+ smtpmail-queue-counter))) - smtpmail-queue-dir)) - (file-data (convert-standard-filename file-data)) - (file-elisp (concat file-data ".el")) - (buffer-data (create-file-buffer file-data))) - (unless (file-exists-p smtpmail-queue-dir) - (make-directory smtpmail-queue-dir t)) - (with-current-buffer buffer-data - (erase-buffer) - (set-buffer-file-coding-system - ;; We will be reading the file with no-conversion in - ;; smtpmail-send-queued-mail below, so write it out - ;; with Unix EOLs. - (coding-system-change-eol-conversion - (or smtpmail-code-conv-from 'undecided) - 'unix) - nil t) - (insert-buffer-substring tembuf) - (write-file file-data) - (let ((coding-system-for-write 'utf-8)) - (with-temp-buffer - (insert "(setq ") - (dolist (var (cons 'smtpmail-recipient-address-list - ;; Perhaps store the server etc. - (and smtpmail-store-queue-variables - smtpmail--stored-queue-variables))) - (insert (format " %s %S\n" var (symbol-value var)))) - (insert ")\n") - (write-region (point-min) (point-max) file-elisp - nil 'silent))) - (write-region (concat file-data "\n") nil - (expand-file-name smtpmail-queue-index-file - smtpmail-queue-dir) - t 'silent)) - (kill-buffer buffer-data)))) - (kill-buffer tembuf) - (if (bufferp errbuf) - (kill-buffer errbuf))))) + (let ((smtpmail-code-conv-from + (if enable-multibyte-characters + (let ((sendmail-coding-system smtpmail-code-conv-from)) + (select-message-coding-system))))) + (smtpmail-prepare-mail tembuf smtpmail-code-conv-from) + (if smtpmail-queue-mail + (smtpmail-queue-mail tembuf smtpmail-code-conv-from) + (smtpmail-send-mail tembuf))) + (kill-buffer tembuf)))) ;;;###autoload (defun smtpmail-send-queued-mail () -- 2.40.0 --=-=-= Content-Type: text/plain -- Manuel Giraud --=-=-=-- From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 May 2023 11:48:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16837192399508 (code B ref 63311); Wed, 10 May 2023 11:48:02 +0000 Received: (at 63311) by debbugs.gnu.org; 10 May 2023 11:47:19 +0000 Received: from localhost ([127.0.0.1]:45416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwiHu-0002TI-UC for submit@debbugs.gnu.org; Wed, 10 May 2023 07:47:19 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:31282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pwiHq-0002T4-Kv for 63311@debbugs.gnu.org; Wed, 10 May 2023 07:47:18 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=47OcNKKi q2TcJtDlE4ysxolI6y6BzPDEZtU+QgNTT5s=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=CJu11UiJ8WXJGDz0iDH0k/bEY44zTu Y5PR5sSbmO+CzTdzdDq1Mwuo878rhzFMvaccHHnOKaQ+JcgolN5Ni8AA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=47OcNKKiq2TcJtDl E4ysxolI6y6BzPDEZtU+QgNTT5s=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=TDYOpt1o/sW18EMfOkGzsGp/fb8dk9mWAb4Gnd Ox9gR1WIG6xRxaPYCEX9WHRftuRW9wHO/GZLyS55NhGx+AmvVmxUrVuDOyEe4yFQV1mOGP zNWAw+llEnpqKVccdTuR/LOsqxXa5nDXH9OrxgLmLB//GGMD+sEQZQSvNq2GaAReEV2Opa RONYsoctRM3sqHtWUzz3Hgl9mJ9uy6j7jESE7g7wDqsft239xJS4L+BP1R668MRIRvL9rx 4eqzbajD4gyy0L0GnmAwMEWEjXN1z0PFFccF8q33Wkkn/hQMkPgPAdJijrU1b0QKG+J8/8 7LtiE+JWyhUkbOcvpcr3vQOg== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id ef4a89a5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 10 May 2023 13:47:12 +0200 (CEST) From: Manuel Giraud In-Reply-To: <87wn1hzv9j.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Tue, 09 May 2023 11:52:56 +0200") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <83ttwqhahy.fsf@gnu.org> <874joq34bk.fsf@ledu-giraud.fr> <83o7mygevr.fsf@gnu.org> <87wn1hzv9j.fsf@ledu-giraud.fr> Date: Wed, 10 May 2023 13:47:11 +0200 Message-ID: <871qjoe7cw.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli, My strategy after the previous patch is summed up by this function: --8<---------------cut here---------------start------------->8--- (defun smtpmail-async-send-it (cleanups) (let ((tembuf (generate-new-buffer " smtpmail temp")) (smtpmail-code-conv-from (if enable-multibyte-characters (let ((sendmail-coding-system smtpmail-code-conv-from)) (select-message-coding-system))))) (smtpmail-prepare-mail tembuf smtpmail-code-conv-from) (push #'(lambda () (kill-buffer tembuf)) cleanups) (make-thread #'(lambda () (smtpmail-send-mail tembuf) (mapc #'funcall cleanups))))) --8<---------------cut here---------------end--------------->8--- That is, I'd like carry around a 'cleanups' list that holds all the functions that needed to be called after the mail was sent. I then need to propagate this 'cleanups' parameter to callers of 'smtpmail-send-it'. The problem is that encounter code with the following form: --8<---------------cut here---------------start------------->8--- (unwind-protect (let (haha) (do) (many) (things) (smtpmail-send-it-or-one-of-its-caller) (run) (other) (stuff)) (kill-some-top-level-buffer)) --8<---------------cut here---------------end--------------->8--- I'm tempted to put '(run)(other)(stuff)(kill-some-top-level-buffer)' into the cleanups list and remove the unwind-protect but then if something goes wrong before sending the mail the '(kill-some-top-level-buffer)' part won't be called. OTOH, if I let the '(unwind-protect=E2=80=A6 (kill-some-top-level-buffer)' in place I could s= hoot myself in the foot with the code that use this buffer into the thread. So I guess, my question is how does one mix Lisp thread with unwind-protect? Best regards, --=20 Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 May 2023 13:28:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168381165331672 (code B ref 63311); Thu, 11 May 2023 13:28:02 +0000 Received: (at 63311) by debbugs.gnu.org; 11 May 2023 13:27:33 +0000 Received: from localhost ([127.0.0.1]:50062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1px6KT-0008El-5Z for submit@debbugs.gnu.org; Thu, 11 May 2023 09:27:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1px6KR-0008EU-7M for 63311@debbugs.gnu.org; Thu, 11 May 2023 09:27:31 -0400 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 1px6KL-0003il-Dw; Thu, 11 May 2023 09:27:25 -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=lHzpoiKqdx7uMy6G5XMP32Db7x3jrgTDuv1qnA0wFrw=; b=Yc2Tdp8gGkuy A7aQIm4p6dBXLEvaPRzuLo+hE/dPtwfzVpbdNgusvEteodZ/vAa1yLGBN3ytUfyuxCq4N1KIEHzai h92pJCgKiSI6/H/zh+wBgOkiAGLNEyTE2b19L3kv9Gr05uk8GXMVLT/BxGdzPxXSH2JDZulW8WpKB INXDHwSpSRVbYABQ/2Xg6BEIvIUpcMKkcmzf+3vpPXxGTvtBpEv77uFRLZY6Kqb0JTQ3BCi+LaMb/ hRrRtFJJPLRk/dYs/aN3XTMgsqtyEZk6uHaMRD6lr1osEhmWJZWMflwR9EcNPwWMaZ9L83m9xqRNV BIcwlIw3Nk6ohyAAVsvDCQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1px6KK-0002tX-Tm; Thu, 11 May 2023 09:27:25 -0400 Date: Thu, 11 May 2023 16:28:33 +0300 Message-Id: <837ctf575q.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871qjoe7cw.fsf@ledu-giraud.fr> (message from Manuel Giraud on Wed, 10 May 2023 13:47:11 +0200) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Wed, 10 May 2023 13:47:11 +0200 > > So I guess, my question is how does one mix Lisp thread with > unwind-protect? I'm not sure I understand why you need to. The two unwind-protect handlers will run at different times and most probably will need to unwind different stuff, although there could be overlap. So why is it a problem to have two separate unwind forms? From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 11 May 2023 21:00:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168383876921061 (code B ref 63311); Thu, 11 May 2023 21:00:02 +0000 Received: (at 63311) by debbugs.gnu.org; 11 May 2023 20:59:29 +0000 Received: from localhost ([127.0.0.1]:53534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxDNp-0005Tc-3a for submit@debbugs.gnu.org; Thu, 11 May 2023 16:59:29 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:23771) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxDNm-0005TR-R6 for 63311@debbugs.gnu.org; Thu, 11 May 2023 16:59:28 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=JdZz0fp4 QDd3QDQXEkvkh8zkdJGNgMxSLPaL++51mog=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=l4fWshQ2D+osptB5PtBoYlteQt4fEX oIfmTnVsNppquO0bbNllV+SzQvRYQSZrWqSjePdfHO2E8Zg73ca4KNDA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=JdZz0fp4QDd3QDQX Ekvkh8zkdJGNgMxSLPaL++51mog=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=d9hZ3DCeSovTHAEoFKR2+jPNIFKNEvau6IY/hK dpXZ8xFVMyvq2LnfWlSnadpKThRMH5gyXzwavXZKlah7Q0QxzG/BklJE9GE0wFnh5smuLJ qlKc2cpqtvKrSZ66+ofuoM/ZbHYEVftH3mUhUnWtKVhuC52DVUHGi6g4PU0APY5bpdPUWE vVLoXDbRLeb+0VD2YNWzAIzS8iU7oXLUINTf5iKT6q/k7MvAgmSlGZuI7uqcK+vRK3kkDG woC/F9LbQ382Svr99m9r1i5zFeBzXsYe0osKhUJdgIBo1MphIMSV0YJolj7ryvTWgZFIec pbChHSz2cBdocokC8ttf4fVg== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id c209fb75 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 11 May 2023 22:59:24 +0200 (CEST) From: Manuel Giraud In-Reply-To: <837ctf575q.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 11 May 2023 16:28:33 +0300") 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> Date: Thu, 11 May 2023 22:59:20 +0200 Message-ID: <87ilcypot3.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 63311@debbugs.gnu.org >> Date: Wed, 10 May 2023 13:47:11 +0200 >> >> So I guess, my question is how does one mix Lisp thread with >> unwind-protect? > > I'm not sure I understand why you need to. The two unwind-protect > handlers will run at different times and most probably will need to > unwind different stuff, although there could be overlap. So why is it > a problem to have two separate unwind forms? I was not talking about two separate unwind forms. I was talking about *thread* and unwind. Here is a minimal example that exhibits my problem: --8<---------------cut here---------------start------------->8--- (setq-local lexical-binding t) (defun my-problem () (interactive) (let ((buf (generate-new-buffer "*foo*"))) (with-current-buffer buf (insert "secret message")) (unwind-protect (make-thread #'(lambda () (with-current-buffer buf (sit-for 10) (message (buffer-string))))) (kill-buffer buf)))) --8<---------------cut here---------------end--------------->8--- The thread won't have a chance to do its job since the buffer will already be dead. -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 May 2023 05:41:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168387004422512 (code B ref 63311); Fri, 12 May 2023 05:41:02 +0000 Received: (at 63311) by debbugs.gnu.org; 12 May 2023 05:40:44 +0000 Received: from localhost ([127.0.0.1]:53800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxLWG-0005r2-9O for submit@debbugs.gnu.org; Fri, 12 May 2023 01:40:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54064) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxLWE-0005qo-PM for 63311@debbugs.gnu.org; Fri, 12 May 2023 01:40:43 -0400 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 1pxLW9-0004YI-1P; Fri, 12 May 2023 01:40:37 -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=z9pNxXafUSXiq3NmqVfNpjVrv/BwruPr1ypARIaU6tU=; b=dART8eilJT1y js4O44Zyb9aENIaTKtkSrOoPUCsh/7mR9JgTVnLNsnl0rYfatiS50SmBO/wOANnyeJzlmIDvTEygw kUjrQOMaZwAgnaqxT1NIi9ivclsBmTkygrU2yM4r8DyqpNzQkXpQ4FPfa1aZj6USx28PvDDsKJBQO bUWrC7/vKzbAIhhCscLmGXn1A172vujkyvxYoRfZuM9TyqrZWmN2T5L6qhlH74Sy7CBJGMzUIZdzG Erxn3s/pK9vJjTUF4zNpVuSYF/6mH4Nu1UGUVLABwUkFD2AGYr0q4FkWHss2eUiY0kJE4wRSMzGAN KmiEMIjEmSvi2KDCXoTcng==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxLW6-0002F6-HQ; Fri, 12 May 2023 01:40:36 -0400 Date: Fri, 12 May 2023 08:41:44 +0300 Message-Id: <83pm763y3r.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ilcypot3.fsf@ledu-giraud.fr> (message from Manuel Giraud on Thu, 11 May 2023 22:59:20 +0200) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Thu, 11 May 2023 22:59:20 +0200 > > (defun my-problem () > (interactive) > (let ((buf (generate-new-buffer "*foo*"))) > (with-current-buffer buf > (insert "secret message")) > (unwind-protect > (make-thread #'(lambda () > (with-current-buffer buf > (sit-for 10) > (message (buffer-string))))) > (kill-buffer buf)))) > --8<---------------cut here---------------end--------------->8--- > > The thread won't have a chance to do its job since the buffer will > already be dead. Of course. So you cannot do that, obviously. Cleanup that gets in the way of code you run in a thread must be done after thread-join returns, or when thread-live-p returns nil for the thread. Or use some other synchronization method. There could be several such threads alive at the same time, btw. In the unwind-protect handler of the main thread you can only do cleanup of stuff that the thread doesn't need, or if you are sure the thread was not started (due to some error that precludes the call to make-thread). I'm not aware of any other machinery we have for these cases. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 May 2023 06:25: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168387268227308 (code B ref 63311); Fri, 12 May 2023 06:25:01 +0000 Received: (at 63311) by debbugs.gnu.org; 12 May 2023 06:24:42 +0000 Received: from localhost ([127.0.0.1]:53819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxMCo-00076N-0S for submit@debbugs.gnu.org; Fri, 12 May 2023 02:24:42 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:7010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxMCl-00076C-Oe for 63311@debbugs.gnu.org; Fri, 12 May 2023 02:24:41 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=JmEWDQGI Mf/pWOL4OBtJr/YR5WdA2UxZQ875d2YPquU=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=JJ1JWB7oB+CuRA60sP6GpKVkW4bXzQ Wd+HOoBsO2PMhHLmngwifIUCrEOdI8m8sbVXQjZ7OEFHcboqJ3gicZDQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=JmEWDQGIMf/pWOL4 OBtJr/YR5WdA2UxZQ875d2YPquU=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=ErF5di0Z+qBKajcSlJHIFOWPTxFfDuTyASX8Yd N8vRzP/RzFsojtcUMU0GkpatbWjMPDI52A2XGcHcML3T9pAKyZd2srWKzN1/JHKZ4jhsM6 FXtyU7adyoiSwKoTcr+0ccgICY9PEcmbVyhmsADk3zHiaN5DP+gTp5BRKTajjwNrQk+APb 5aKEmZZzfpsg6kUZo5qCvGnv4T/8gAuwsYauBzNwnOSdA8J+MKNChxUaFnslaSGqbnEQoL /kTM5KIVcRXDC4aV5Kxw/gJFE3HcNvqo8LRuPftKWDGYEYxTwWfD1DZVyO7MmfIoiOZjI/ Jee7D5sSjzQfsRXW/NCoBcbA== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id e5d4248c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 12 May 2023 08:24:37 +0200 (CEST) From: Manuel Giraud In-Reply-To: <83pm763y3r.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 May 2023 08:41:44 +0300") 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> Date: Fri, 12 May 2023 08:24:36 +0200 Message-ID: <87h6si5aor.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 63311@debbugs.gnu.org >> Date: Thu, 11 May 2023 22:59:20 +0200 >>=20 >> (defun my-problem () >> (interactive) >> (let ((buf (generate-new-buffer "*foo*"))) >> (with-current-buffer buf >> (insert "secret message")) >> (unwind-protect >> (make-thread #'(lambda () >> (with-current-buffer buf >> (sit-for 10) >> (message (buffer-string))))) >> (kill-buffer buf)))) >> --8<---------------cut here---------------end--------------->8--- >>=20 >> The thread won't have a chance to do its job since the buffer will >> already be dead. > > Of course. So you cannot do that, obviously. Cleanup that gets in > the way of code you run in a thread must be done after thread-join > returns, or when thread-live-p returns nil for the thread. Or use > some other synchronization method. There could be several such > threads alive at the same time, btw. > > In the unwind-protect handler of the main thread you can only do > cleanup of stuff that the thread doesn't need, or if you are sure the > thread was not started (due to some error that precludes the call to > make-thread). Thanks! So I could go with something like this: --8<---------------cut here---------------start------------->8--- (setq-local lexical-binding t) (defun eli-solution () (interactive) (let ((buf (generate-new-buffer "*foo*"))) (with-current-buffer buf (insert "secret message")) (let ((cleanup #'(lambda () (kill-buffer buf))) thread) (unwind-protect (setf thread (make-thread #'(lambda () (with-current-buffer buf (sit-for 10) (message (buffer-string)) (funcall cleanup))))) (unless (thread-live-p thread) (funcall cleanup)))))) --8<---------------cut here---------------end--------------->8--- BTW, do you know a more elisp way of defining a function than "(let ((f #'(lambda=E2=80=A6))))" form? --=20 Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 May 2023 07:09: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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168387532931430 (code B ref 63311); Fri, 12 May 2023 07:09:01 +0000 Received: (at 63311) by debbugs.gnu.org; 12 May 2023 07:08:49 +0000 Received: from localhost ([127.0.0.1]:53889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxMtV-0008As-97 for submit@debbugs.gnu.org; Fri, 12 May 2023 03:08:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxMtT-0008Ad-Eb for 63311@debbugs.gnu.org; Fri, 12 May 2023 03:08:48 -0400 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 1pxMtN-0002lm-Ea; Fri, 12 May 2023 03:08:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=gEBuYvZNMWuSAfXaP0Ea3MFiSo6cqUCRPGvPJiP+AU0=; b=d/DxJYd0mjzK6Asv7VEv ZE3D6Jchf5e0XuD05hGQTSviHEvbBEZW3QDr491XdGy4uOtl9xZx439whv78sdBBgpLnZUt25wQqN SL9Np1lVo91VL/DpgEQl0bCIoiPStMbQwvuUfujsJpL4Hj0frfJLZFyQNdSP3Dq/bP7qb2wo0fZdC l50VwiGSgY59SUNkYzZh14T0eYgJVFBb7kJnHyKllML9zzTKSB2CLJ4LB2t0AGMomg5mU/eBXzqdW uHv1f80risgWTTbpkP4XhdarZF6Uj/8AhuBKb5bG9t6AWGIKX68GrmvrLOZipqtSaLx5YNEZMSZo0 gAxPCCUUXtvyqw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pxMtG-0000VZ-Gb; Fri, 12 May 2023 03:08:41 -0400 Date: Fri, 12 May 2023 10:09:41 +0300 Message-Id: <83a5ya3u16.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87h6si5aor.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 12 May 2023 08:24:36 +0200) 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Fri, 12 May 2023 08:24:36 +0200 > > (setq-local lexical-binding t) > > (defun eli-solution () > (interactive) > (let ((buf (generate-new-buffer "*foo*"))) > (with-current-buffer buf > (insert "secret message")) > (let ((cleanup #'(lambda () (kill-buffer buf))) > thread) > (unwind-protect > (setf thread (make-thread #'(lambda () > (with-current-buffer buf > (sit-for 10) > (message (buffer-string)) > (funcall cleanup))))) > (unless (thread-live-p thread) > (funcall cleanup)))))) Yes, something like that. > BTW, do you know a more elisp way of defining a function than > "(let ((f #'(lambda…))))" form? I'm not sure I understand: what's not ELisp'y about that? And why not use defun instead? From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Ruijie Yu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 May 2023 07:11:02 +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 To: Manuel Giraud Cc: Eli Zaretskii , 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.168387543031616 (code B ref 63311); Fri, 12 May 2023 07:11:02 +0000 Received: (at 63311) by debbugs.gnu.org; 12 May 2023 07:10:30 +0000 Received: from localhost ([127.0.0.1]:53894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxMv7-0008Ds-Oh for submit@debbugs.gnu.org; Fri, 12 May 2023 03:10:29 -0400 Received: from netyu.xyz ([152.44.41.246]:50384 helo=mail.netyu.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxMv6-0008Dl-Qi for 63311@debbugs.gnu.org; Fri, 12 May 2023 03:10:29 -0400 Received: from fw.net.yu.netyu.xyz ( [222.248.4.98]) by netyu.xyz (OpenSMTPD) with ESMTPSA id 629ac461 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 12 May 2023 07:10:27 +0000 (UTC) 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> User-agent: mu4e 1.11.3; emacs 30.0.50 From: Ruijie Yu In-reply-to: <87h6si5aor.fsf@ledu-giraud.fr> Date: Fri, 12 May 2023 15:10:21 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text = editors" writes: > BTW, do you know a more elisp way of defining a function than > "(let ((f #'(lambda=E2=80=A6))))" form? First of all, I believe you can always get rid of the function quote because =CE=BB is a self-evaluating form. Not quite sure if `lexical-binding' makes a difference here though. Option 1: ```emacs-lisp (eval-when-compile (require 'cl-macs)) (cl-flet ((f (arg) 'expressions)) (f arg)) ``` Option 2: ```emacs-lisp (eval-when-compile (require 'cl-macs)) (cl-letf (((symbol-function 'f) (lambda (arg) 'expression))) (f arg)) ``` --=20 Best, RY From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 May 2023 07:58: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16838782334788 (code B ref 63311); Fri, 12 May 2023 07:58:01 +0000 Received: (at 63311) by debbugs.gnu.org; 12 May 2023 07:57:13 +0000 Received: from localhost ([127.0.0.1]:54004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNeL-0001FA-HZ for submit@debbugs.gnu.org; Fri, 12 May 2023 03:57:13 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:32749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pxNeJ-0001F0-6w for 63311@debbugs.gnu.org; Fri, 12 May 2023 03:57:12 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=6WfNubpy ncNVUgMHkVNK1rdoyOXiCRofp6sHICAxmis=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=x6CJo8PT4hsZAb9XjsSZ7KueWPd+2Q ClATKYzi5nxbPi/nGzs5mHZkdfC4hqWkvI6TaxFLe6g8G8YL8ZdKOSDQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=6WfNubpyncNVUgMH kVNK1rdoyOXiCRofp6sHICAxmis=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=f7tvU0JAsiH5M6FX1bJrWj8QKfH/FcApV49Ag9 MCe91UuamwaFTZMOzeWBmcraTzfPDyQ6Dwpld4yLgu+orhWOeoqyZfg4Ai+mffoKJqRo5l Ceh/9e1ZL691z+FmWq/OtoZeeULY0KTnd9ksuPRAZsFIJuTEUMMrhFhyKt3+7KZqBfcgrq yi3gTCAbj56pE2aPhqLKgSe9u2xYAjIrCQfrVzESBToe+B9dPC5Ejmk7jltTErUENoA8bq rUAcfI9G2qqCPjNBv1TqZQjIz4p33zONZ2A8bCVb1VQtTxq7QzKmgZQdpyD0K/HV1UlREx xeiskPvSdbkwW3N8yWE5MNog== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 64723612 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 12 May 2023 09:57:09 +0200 (CEST) From: Manuel Giraud In-Reply-To: <83a5ya3u16.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 May 2023 10:09:41 +0300") 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> Date: Fri, 12 May 2023 09:57:08 +0200 Message-ID: <871qjm56ej.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] >> BTW, do you know a more elisp way of defining a function than >> "(let ((f #'(lambda=E2=80=A6))))" form? > > I'm not sure I understand: what's not ELisp'y about that? I meant what is the most idiomatic. As Ruijie Yu said, there is also Common Lisp extensions that are cleaner but will also add a new dependency into "smtpmail.el" and "message.el". > And why not use defun instead? I'll try that. --=20 Manuel Giraud From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 04 04:30:19 2023 Received: (at control) by debbugs.gnu.org; 4 Sep 2023 08:30:19 +0000 Received: from localhost ([127.0.0.1]:48347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qd4yQ-0006Cu-Lc for submit@debbugs.gnu.org; Mon, 04 Sep 2023 04:30:18 -0400 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:59651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qd4yO-0005pP-ON for control@debbugs.gnu.org; Mon, 04 Sep 2023 04:30:17 -0400 Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2bcd7a207f7so16416991fa.3 for ; Mon, 04 Sep 2023 01:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693816211; x=1694421011; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=RhisDGUCZPgFwaV8mw6FCCq48WmQy8VLSwVcfN2KhZA=; b=i/NLNputgV4mUH8UviLcO0cURB6+q+WNmKV2fCcT91m1eAMj60QQg7rcC7/mGLJ2yb 6NImvXJb9T/ZpVI2sNwUUxXxSNV4vbM9zP5OlIANqlckrmtVR2ZjNYIQCZHIisEqf3SL N4wVligFFJ0zEVdZllUf9vD06WRdbjT2qIwMOqCMjSCgOQuxn9u/50nyM4vhUVNRdJN0 ob2D9dQ+MhysJb/jg09gQ0ZXflkKkJSIoA9a4do+jUEECnAAh29KsXsgrXfQ+sgmtBID /fBqRKkJgvVmhQx4kAO9bBnF83nywGS2aDghCUAJFu+tXEkHgeo/PAyvgD00QLKz9XG3 pVUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693816211; x=1694421011; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RhisDGUCZPgFwaV8mw6FCCq48WmQy8VLSwVcfN2KhZA=; b=ZOHjhrPxYNr7Qxd6JHsN23d8wFA7M5aUAVVBNEYxbUCpcKy96xXbL+lqTI3q1ujktm 3tqYaMvLFptAVVWYJUoVs2q4fE2ufogQoo7rFHdTg9Ky2tX+f43fHBZDntGzY1ohpNPR YV3/P+F8ccIDIVialvOXakmz7BxtW+zK4uXeoyQK6rghWN2qbLWEclmSMqyi5Idm7ST8 wh/bT3MSwCmkwEpNKVifxqs/tv17E/LICJ6+Cxb0RK2A6mNWrWyqb+Cb+/nHrQOzxXFy lpiAuL4AmAX6R8vrdqE7QMcLsdWU+mvjKp9c1Uz90XazEtLlBixhb73SEVVW5BAb9WzU 49vA== X-Gm-Message-State: AOJu0Yxefd3SQ86jj6ox/v4IUeEMCnVX+ZlhtLS5RURfjdTYGWl9fC32 o13ee1yscgOwx5tmLdl5d7yuQbhW2BAR2upgiRJWYAOvlSQ= X-Google-Smtp-Source: AGHT+IFR3gqliknsxSTPUyyYzgC0F0vMhNrbJUvoU69rL0BxdL+WNyT6+ZsGvhXQWld73U9GfSg8Vc6gepYdkcGXeFg= X-Received: by 2002:ac2:592a:0:b0:500:8146:9ebc with SMTP id v10-20020ac2592a000000b0050081469ebcmr5897355lfi.47.1693816211025; Mon, 04 Sep 2023 01:30:11 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 4 Sep 2023 01:30:10 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Mon, 4 Sep 2023 01:30:10 -0700 Message-ID: Subject: control message for bug #63311 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 63311 wishlist quit From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 12:37: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169884219325867 (code B ref 63311); Wed, 01 Nov 2023 12:37:01 +0000 Received: (at 63311) by debbugs.gnu.org; 1 Nov 2023 12:36:33 +0000 Received: from localhost ([127.0.0.1]:50116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyAST-0006j1-AY for submit@debbugs.gnu.org; Wed, 01 Nov 2023 08:36:33 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:13749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyASM-0006il-SR for 63311@debbugs.gnu.org; Wed, 01 Nov 2023 08:36:27 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=DG1dAG5x IxfT4aqyXy3gVvNk7uY2LguZSM/fT2QcbJE=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=8w7hm5LF8Pw7esBRCV2iq/CwRJpTKO /ykKEy8YJnYNmQScMdhe31OLS2twK7MH0doD4PJo4uzalvEshViwriBQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=DG1dAG5xIxfT4aqy Xy3gVvNk7uY2LguZSM/fT2QcbJE=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=yMmYqThtoZJyYtiUl9VyYOZrwobWSLTE1UNOot HnwnKE1r9FP5JyF+PnEWSnU6asRaqvxgB+DLBYGUa+zAZ/FWkxLkzX3JKFEjaN/Xk82k1L GnLX5gNMETOlbMfnhWBoYhxzVJn5xv5lkAwwMWagrzZbYsn4rptuBDGYvLrA7j7ybwZGJX Nc20uCTZxZQoTOMYdRNQ0jN8/4CCehrWzeMqbjF9UfueZvHZJJ4rrK8TdzhNgLk7d2asQ1 XYyJ5iEaRe+cMHPNlc+jwzoZKHMHRq64Pu+HPpbm53wRMAVyZY4+5QzY4juFsxykDm0wj2 z6cBzyoYcJUFs0+fmVHiLzAw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 695bcaaa (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 1 Nov 2023 13:35:46 +0100 (CET) From: Manuel Giraud In-Reply-To: <871qjm56ej.fsf@ledu-giraud.fr> (Manuel Giraud's message of "Fri, 12 May 2023 09:57:08 +0200") 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> Date: Wed, 01 Nov 2023 13:35:45 +0100 Message-ID: <87r0l9ejmm.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Hi, 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. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-smtpmail-send-it-split-and-async.patch >From 1c105e1c70d290bc4e7dfe8180d1a210daa76f05 Mon Sep 17 00:00:00 2001 From: Manuel Giraud Date: Fri, 5 May 2023 14:35:01 +0200 Subject: [PATCH] smtpmail-send-it split and async * lisp/mail/smtpmail.el (smtpmail-prepare-mail): New function that prepares the mail with current buffer content. (smtpmail-queue-mail): New function to queue a mail (prepared by 'smtpmail-prepare-mail'). (smtpmail-send-mail): New function to send a mail (prepared by 'smtpmail-send-mail'). (smtpmail-send-it): Use all three previous functions. Use a thread to async 'smtpmail-send-mail'. While here, remove 'errbuf' leftovers. --- lisp/mail/smtpmail.el | 421 +++++++++++++++++++++--------------------- 1 file changed, 213 insertions(+), 208 deletions(-) diff --git a/lisp/mail/smtpmail.el b/lisp/mail/smtpmail.el index 78688d170cc..a69aa027c0a 100644 --- a/lisp/mail/smtpmail.el +++ b/lisp/mail/smtpmail.el @@ -205,217 +205,222 @@ smtpmail-mail-address "Value to use for envelope-from address for mail from ambient buffer.") ;;; Functions +(defun smtpmail-prepare-mail (tembuf smtpmail-code-conv-from) + (let ((case-fold-search nil) + delimline + (mailbuf (current-buffer)) + ;; Examine this variable now, so that + ;; local binding in the mail buffer will take effect. + (smtpmail-mail-address + (save-restriction + ;; Only look at the headers when fetching the + ;; envelope address. + (message-narrow-to-headers) + (or (and mail-specify-envelope-from (mail-envelope-from)) + (let ((from (mail-fetch-field "from"))) + (and from + (cadr (mail-extract-address-components from)))) + (smtpmail-user-mail-address))))) + (with-current-buffer tembuf + (erase-buffer) + ;; Use the same `buffer-file-coding-system' as in the mail + ;; buffer, otherwise any `write-region' invocations (e.g., in + ;; mail-do-fcc below) will annoy with asking for a suitable + ;; encoding. + (set-buffer-file-coding-system smtpmail-code-conv-from nil t) + (insert-buffer-substring mailbuf) + (goto-char (point-max)) + ;; require one newline at the end. + (or (= (preceding-char) ?\n) + (insert ?\n)) + ;; Change header-delimiter to be what sendmail expects. + (mail-sendmail-undelimit-header) + (setq delimline (point-marker)) + (if mail-aliases + (expand-mail-aliases (point-min) delimline)) + (goto-char (point-min)) + ;; ignore any blank lines in the header + (while (and (re-search-forward "\n\n\n*" delimline t) + (< (point) delimline)) + (replace-match "\n")) + (let ((case-fold-search t)) + ;; We used to process Resent-... headers here, + ;; but it was not done properly, and the job + ;; is done correctly in `smtpmail-deduce-address-list'. + ;; Don't send out a blank subject line + (goto-char (point-min)) + (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) + (replace-match "") + ;; This one matches a Subject just before the header delimiter. + (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) + (= (match-end 0) delimline)) + (replace-match ""))) + ;; Put the "From:" field in unless for some odd reason + ;; they put one in themselves. + (goto-char (point-min)) + (if (not (re-search-forward "^From:" delimline t)) + (let* ((login smtpmail-mail-address) + (fullname (user-full-name))) + (cond ((eq mail-from-style 'angles) + (insert "From: " fullname) + (let ((fullname-start (+ (point-min) 6)) + (fullname-end (point-marker))) + (goto-char fullname-start) + ;; Look for a character that cannot appear unquoted + ;; according to RFC 822 or its successors. + (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" + fullname-end 1) + (progn + ;; Quote fullname, escaping specials. + (goto-char fullname-start) + (insert "\"") + (while (re-search-forward "[\"\\]" + fullname-end 1) + (replace-match "\\\\\\&" t)) + (insert "\"")))) + (insert " <" login ">\n")) + ((eq mail-from-style 'parens) + (insert "From: " login " (") + (let ((fullname-start (point))) + (insert fullname) + (let ((fullname-end (point-marker))) + (goto-char fullname-start) + ;; RFC 822 and its successors say \ and + ;; nonmatching parentheses must be + ;; escaped in comments. + ;; Escape every instance of ()\ ... + (while (re-search-forward "[()\\]" fullname-end 1) + (replace-match "\\\\\\&" t)) + ;; ... then undo escaping of matching parentheses, + ;; including matching nested parentheses. + (goto-char fullname-start) + (while (re-search-forward + "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" + fullname-end 1) + (replace-match "\\1(\\3)" t) + (goto-char fullname-start)))) + (insert ")\n")) + ((null mail-from-style) + (insert "From: " login "\n"))))) + ;; Insert a `Message-Id:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Message-Id:" delimline t) + (insert "Message-Id: " (message-make-message-id) "\n")) + ;; Insert a `Date:' field if there isn't one yet. + (goto-char (point-min)) + (unless (re-search-forward "^Date:" delimline t) + (insert "Date: " (message-make-date) "\n")) + ;; Possibly add a MIME header for the current coding system + (let (charset) + (goto-char (point-min)) + (and (eq mail-send-nonascii 'mime) + (not (re-search-forward "^MIME-version:" delimline t)) + (progn (skip-chars-forward "\0-\177") + (/= (point) (point-max))) + smtpmail-code-conv-from + (setq charset + (coding-system-get smtpmail-code-conv-from + 'mime-charset)) + (goto-char delimline) + (insert "MIME-version: 1.0\n" + "Content-type: text/plain; charset=" + (symbol-name charset) + "\nContent-Transfer-Encoding: 8bit\n"))) + ;; Insert an extra newline if we need it to work around + ;; Sun's bug that swallows newlines. + (goto-char (1+ delimline)) + ;; Find and handle any Fcc fields. + (goto-char (point-min)) + (if (re-search-forward "^Fcc:" delimline t) + ;; Force `mail-do-fcc' to use the encoding of the mail + ;; buffer to encode outgoing messages on Fcc files. + (let ((coding-system-for-write + ;; mbox files must have Unix EOLs. + (coding-system-change-eol-conversion + smtpmail-code-conv-from 'unix))) + (mail-do-fcc delimline)))) + ;; Encode the header according to RFC2047. + (mail-encode-header (point-min) delimline) + ;; + (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) + (setq smtpmail-recipient-address-list + (smtpmail-deduce-address-list tembuf (point-min) delimline)) + (kill-buffer smtpmail-address-buffer) + + (smtpmail-do-bcc delimline)))) + +(defun smtpmail-queue-mail (tembuf smtpmail-code-conv-from) + (let* ((file-data + (expand-file-name + (format "%s_%i" + (format-time-string "%Y-%m-%d_%H:%M:%S") + (setq smtpmail-queue-counter + (1+ smtpmail-queue-counter))) + smtpmail-queue-dir)) + (file-data (convert-standard-filename file-data)) + (file-elisp (concat file-data ".el")) + (buffer-data (create-file-buffer file-data))) + (unless (file-exists-p smtpmail-queue-dir) + (make-directory smtpmail-queue-dir t)) + (with-current-buffer buffer-data + (erase-buffer) + (set-buffer-file-coding-system + ;; We will be reading the file with no-conversion in + ;; smtpmail-send-queued-mail below, so write it out + ;; with Unix EOLs. + (coding-system-change-eol-conversion + (or smtpmail-code-conv-from 'undecided) + 'unix) + nil t) + (insert-buffer-substring tembuf) + (write-file file-data) + (let ((coding-system-for-write 'utf-8)) + (with-temp-buffer + (insert "(setq ") + (dolist (var (cons 'smtpmail-recipient-address-list + ;; Perhaps store the server etc. + (and smtpmail-store-queue-variables + smtpmail--stored-queue-variables))) + (insert (format " %s %S\n" var (symbol-value var)))) + (insert ")\n") + (write-region (point-min) (point-max) file-elisp + nil 'silent))) + (write-region (concat file-data "\n") nil + (expand-file-name smtpmail-queue-index-file + smtpmail-queue-dir) + t 'silent)) + (kill-buffer buffer-data))) + +(defun smtpmail-send-mail (tembuf) + (let (result) + (if (not (null smtpmail-recipient-address-list)) + (when (setq result + (smtpmail-via-smtp + smtpmail-recipient-address-list tembuf)) + (error "Sending failed: %s" + (smtpmail--sanitize-error-message result))) + (error "Sending failed; no recipients")))) ;;;###autoload (defun smtpmail-send-it () - (let ((errbuf (if mail-interactive - (generate-new-buffer " smtpmail errors") - 0)) - (tembuf (generate-new-buffer " smtpmail temp")) - (case-fold-search nil) - delimline - result - (mailbuf (current-buffer)) - ;; Examine this variable now, so that - ;; local binding in the mail buffer will take effect. - (smtpmail-mail-address - (save-restriction - ;; Only look at the headers when fetching the - ;; envelope address. - (message-narrow-to-headers) - (or (and mail-specify-envelope-from (mail-envelope-from)) - (let ((from (mail-fetch-field "from"))) - (and from - (cadr (mail-extract-address-components from)))) - (smtpmail-user-mail-address)))) - (smtpmail-code-conv-from - (if enable-multibyte-characters - (let ((sendmail-coding-system smtpmail-code-conv-from)) - (select-message-coding-system))))) - (unwind-protect - (with-current-buffer tembuf - (erase-buffer) - ;; Use the same `buffer-file-coding-system' as in the mail - ;; buffer, otherwise any `write-region' invocations (e.g., in - ;; mail-do-fcc below) will annoy with asking for a suitable - ;; encoding. - (set-buffer-file-coding-system smtpmail-code-conv-from nil t) - (insert-buffer-substring mailbuf) - (goto-char (point-max)) - ;; require one newline at the end. - (or (= (preceding-char) ?\n) - (insert ?\n)) - ;; Change header-delimiter to be what sendmail expects. - (mail-sendmail-undelimit-header) - (setq delimline (point-marker)) - ;; (sendmail-synch-aliases) - (if mail-aliases - (expand-mail-aliases (point-min) delimline)) - (goto-char (point-min)) - ;; ignore any blank lines in the header - (while (and (re-search-forward "\n\n\n*" delimline t) - (< (point) delimline)) - (replace-match "\n")) - (let ((case-fold-search t)) - ;; We used to process Resent-... headers here, - ;; but it was not done properly, and the job - ;; is done correctly in `smtpmail-deduce-address-list'. - ;; Don't send out a blank subject line - (goto-char (point-min)) - (if (re-search-forward "^Subject:\\([ \t]*\n\\)+\\b" delimline t) - (replace-match "") - ;; This one matches a Subject just before the header delimiter. - (if (and (re-search-forward "^Subject:\\([ \t]*\n\\)+" delimline t) - (= (match-end 0) delimline)) - (replace-match ""))) - ;; Put the "From:" field in unless for some odd reason - ;; they put one in themselves. - (goto-char (point-min)) - (if (not (re-search-forward "^From:" delimline t)) - (let* ((login smtpmail-mail-address) - (fullname (user-full-name))) - (cond ((eq mail-from-style 'angles) - (insert "From: " fullname) - (let ((fullname-start (+ (point-min) 6)) - (fullname-end (point-marker))) - (goto-char fullname-start) - ;; Look for a character that cannot appear unquoted - ;; according to RFC 822 or its successors. - (if (re-search-forward "[^- !#-'*+/-9=?A-Z^-~]" - fullname-end 1) - (progn - ;; Quote fullname, escaping specials. - (goto-char fullname-start) - (insert "\"") - (while (re-search-forward "[\"\\]" - fullname-end 1) - (replace-match "\\\\\\&" t)) - (insert "\"")))) - (insert " <" login ">\n")) - ((eq mail-from-style 'parens) - (insert "From: " login " (") - (let ((fullname-start (point))) - (insert fullname) - (let ((fullname-end (point-marker))) - (goto-char fullname-start) - ;; RFC 822 and its successors say \ and - ;; nonmatching parentheses must be - ;; escaped in comments. - ;; Escape every instance of ()\ ... - (while (re-search-forward "[()\\]" fullname-end 1) - (replace-match "\\\\\\&" t)) - ;; ... then undo escaping of matching parentheses, - ;; including matching nested parentheses. - (goto-char fullname-start) - (while (re-search-forward - "\\(\\=\\|[^\\]\\(\\\\\\\\\\)*\\)\\\\(\\(\\([^\\]\\|\\\\\\\\\\)*\\)\\\\)" - fullname-end 1) - (replace-match "\\1(\\3)" t) - (goto-char fullname-start)))) - (insert ")\n")) - ((null mail-from-style) - (insert "From: " login "\n"))))) - ;; Insert a `Message-Id:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Message-Id:" delimline t) - (insert "Message-Id: " (message-make-message-id) "\n")) - ;; Insert a `Date:' field if there isn't one yet. - (goto-char (point-min)) - (unless (re-search-forward "^Date:" delimline t) - (insert "Date: " (message-make-date) "\n")) - ;; Possibly add a MIME header for the current coding system - (let (charset) - (goto-char (point-min)) - (and (eq mail-send-nonascii 'mime) - (not (re-search-forward "^MIME-version:" delimline t)) - (progn (skip-chars-forward "\0-\177") - (/= (point) (point-max))) - smtpmail-code-conv-from - (setq charset - (coding-system-get smtpmail-code-conv-from - 'mime-charset)) - (goto-char delimline) - (insert "MIME-version: 1.0\n" - "Content-type: text/plain; charset=" - (symbol-name charset) - "\nContent-Transfer-Encoding: 8bit\n"))) - ;; Insert an extra newline if we need it to work around - ;; Sun's bug that swallows newlines. - (goto-char (1+ delimline)) - ;; Find and handle any Fcc fields. - (goto-char (point-min)) - (if (re-search-forward "^Fcc:" delimline t) - ;; Force `mail-do-fcc' to use the encoding of the mail - ;; buffer to encode outgoing messages on Fcc files. - (let ((coding-system-for-write - ;; mbox files must have Unix EOLs. - (coding-system-change-eol-conversion - smtpmail-code-conv-from 'unix))) - (mail-do-fcc delimline))) - (if mail-interactive - (with-current-buffer errbuf - (erase-buffer)))) - ;; Encode the header according to RFC2047. - (mail-encode-header (point-min) delimline) - ;; - (setq smtpmail-address-buffer (generate-new-buffer "*smtp-mail*")) - (setq smtpmail-recipient-address-list - (smtpmail-deduce-address-list tembuf (point-min) delimline)) - (kill-buffer smtpmail-address-buffer) - - (smtpmail-do-bcc delimline) - ;; Send or queue - (if (not smtpmail-queue-mail) - (if (not (null smtpmail-recipient-address-list)) - (when (setq result - (smtpmail-via-smtp - smtpmail-recipient-address-list tembuf)) - (error "Sending failed: %s" - (smtpmail--sanitize-error-message result))) - (error "Sending failed; no recipients")) - (let* ((file-data - (expand-file-name - (format "%s_%i" - (format-time-string "%Y-%m-%d_%H:%M:%S") - (setq smtpmail-queue-counter - (1+ smtpmail-queue-counter))) - smtpmail-queue-dir)) - (file-data (convert-standard-filename file-data)) - (file-elisp (concat file-data ".el")) - (buffer-data (create-file-buffer file-data))) - (unless (file-exists-p smtpmail-queue-dir) - (make-directory smtpmail-queue-dir t)) - (with-current-buffer buffer-data - (erase-buffer) - (set-buffer-file-coding-system - ;; We will be reading the file with no-conversion in - ;; smtpmail-send-queued-mail below, so write it out - ;; with Unix EOLs. - (coding-system-change-eol-conversion - (or smtpmail-code-conv-from 'undecided) - 'unix) - nil t) - (insert-buffer-substring tembuf) - (write-file file-data) - (let ((coding-system-for-write 'utf-8)) - (with-temp-buffer - (insert "(setq ") - (dolist (var (cons 'smtpmail-recipient-address-list - ;; Perhaps store the server etc. - (and smtpmail-store-queue-variables - smtpmail--stored-queue-variables))) - (insert (format " %s %S\n" var (symbol-value var)))) - (insert ")\n") - (write-region (point-min) (point-max) file-elisp - nil 'silent))) - (write-region (concat file-data "\n") nil - (expand-file-name smtpmail-queue-index-file - smtpmail-queue-dir) - t 'silent)) - (kill-buffer buffer-data)))) - (kill-buffer tembuf) - (if (bufferp errbuf) - (kill-buffer errbuf))))) + (let ((tembuf (generate-new-buffer " smtpmail temp")) + (smtpmail-code-conv-from + (if enable-multibyte-characters + (let ((sendmail-coding-system smtpmail-code-conv-from)) + (select-message-coding-system))))) + (smtpmail-prepare-mail tembuf smtpmail-code-conv-from) + (cond (smtpmail-queue-mail + (smtpmail-queue-mail tembuf smtpmail-code-conv-from) + (kill-buffer tembuf)) + (t + (let ((cleanup (lambda () (kill-buffer tembuf))) + thread) + (unwind-protect + (setf thread (make-thread (lambda () + (smtpmail-send-mail tembuf) + (funcall cleanup)))) + (unless (thread-live-p thread) + (funcall cleanup)))))))) ;;;###autoload (defun smtpmail-send-queued-mail () -- 2.42.0 --=-=-= Content-Type: text/plain -- Manuel Giraud --=-=-=-- From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 13:01:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169884361929093 (code B ref 63311); Wed, 01 Nov 2023 13:01:02 +0000 Received: (at 63311) by debbugs.gnu.org; 1 Nov 2023 13:00:19 +0000 Received: from localhost ([127.0.0.1]:50174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyApX-0007Z9-0D for submit@debbugs.gnu.org; Wed, 01 Nov 2023 09:00:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyApS-0007Yr-7f for 63311@debbugs.gnu.org; Wed, 01 Nov 2023 09:00:18 -0400 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 1qyAoo-0008VY-4i; Wed, 01 Nov 2023 08:59:34 -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=6YY0dkM/mgNUNfzWcWClMSl+da0H/hCV2/0/vpRduV4=; b=g9Il+5bf2zrR aT8H7hmwIVUtHaVoYI1zc3d1JeIhb2VakbXTbufQZqX+7Aj83YSUeInsIcO5RCYArmEKFOcvbDtRs I97sfLWKBWrEXDKhs8UO5+r0RgYkGqocPvoCkQr7Y9N9YS/GCFPUhDwXrrD7ZWz32M6DyzB7ES4yu A38RqexZxafXwIkjBBTq9dL5YzxcC6KIzoo2tSDD2ALqjVQnjPgu6BNYEW3ULbg1VbNHw9udqQlxQ GTYf3HAnSXiZmuT3AGP+hQtVPdxUnaYgRTI1FxnvigYX3N1dt9q2Efb/pQA+6jrBkQmDbCzBOHNhz oKDtN4wQnXQasySFYHu91w==; Date: Wed, 01 Nov 2023 14:59:23 +0200 Message-Id: <834ji5aatw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87r0l9ejmm.fsf@ledu-giraud.fr> (message from Manuel Giraud on Wed, 01 Nov 2023 13:35:45 +0100) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > 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? . 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? . With which MUA are you testing this? . What happens if another message is sent while the previous one is still being sent? . What did you try to do in Emacs while the message was being sent, and did you see any problems with the foreground 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. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 18:07:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169886201512750 (code B ref 63311); Wed, 01 Nov 2023 18:07:02 +0000 Received: (at 63311) by debbugs.gnu.org; 1 Nov 2023 18:06:55 +0000 Received: from localhost ([127.0.0.1]:52531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyFcB-0003JV-9k for submit@debbugs.gnu.org; Wed, 01 Nov 2023 14:06:55 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:28561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyFc5-0003JF-Tl for 63311@debbugs.gnu.org; Wed, 01 Nov 2023 14:06:50 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=TgpNGjJz zkMiDnKiShzlEa4Zt/wPw3oh916V+lRCmGg=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=kxUw3FxYMjff1oLGncMe8oUf5G0wfV 7RKtr3GP25RQ61+ksCDyMHSMGzGlkHWndWuIHXJ2r1nj20LM2S0LLZBQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=TgpNGjJzzkMiDnKi ShzlEa4Zt/wPw3oh916V+lRCmGg=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=T/QesP8wnStbiVcRHOnmEMJkH5EY2ebm2IrX6q FzbREY2O7qLGNsLHmxDVSppL2NKWUzkg+71RDcakv3s94ijpVCUNfHbDu3wv5B0FlVRUEW +Gw5Yb37/tWs3D6CNMh2HsisGisG1bzPdUcwIXuIiB2VIrcnahn3hTNT5plMG3D9lyTF4f REWyW8ma2hmGZLG6gbMCPHxBCBmO16MtuJKaCPw7/OniUFBIC4+meIch2lqCtwwcLveE5v JyrQb3/mUWFfpEWIsgOGp4iVJ5aES0IP1hFiok4jKHOP9kDkc+bUSBnaI/FVW3d/03pPCV +AlNZoh+wSPl0uBY9RtmQjIQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id bd2b3b93 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 1 Nov 2023 19:06:09 +0100 (CET) From: Manuel Giraud In-Reply-To: <834ji5aatw.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 Nov 2023 14:59:23 +0200") 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> Date: Wed, 01 Nov 2023 19:06:08 +0100 Message-ID: <87bkcde4bz.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> 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 From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split 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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169886704631899 (code B ref 63311); Wed, 01 Nov 2023 19:31:01 +0000 Received: (at 63311) by debbugs.gnu.org; 1 Nov 2023 19:30:46 +0000 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 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 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==; Date: Wed, 01 Nov 2023 21:29:43 +0200 Message-Id: <83r0l98e6w.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87bkcde4bz.fsf@ledu-giraud.fr> (message from Manuel Giraud on Wed, 01 Nov 2023 19:06:08 +0100) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 19:57:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169886858612369 (code B ref 63311); Wed, 01 Nov 2023 19:57:02 +0000 Received: (at 63311) by debbugs.gnu.org; 1 Nov 2023 19:56:26 +0000 Received: from localhost ([127.0.0.1]:52670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyHKA-0003DN-CB for submit@debbugs.gnu.org; Wed, 01 Nov 2023 15:56:26 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:20158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyHK4-0003D7-DA for 63311@debbugs.gnu.org; Wed, 01 Nov 2023 15:56:21 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=HzwMz0JG AcYRco1tyhfK+QrfPYrYVBlIv81X8sn0LPA=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=LLyFKC8ZDNtDP6FQmhj3Epd9Y1Cy1m 8uVLz+saexMRk6CM+qm0rFxqLEvSGpnw1haUAYc/5y6SELMh1+73cBBA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=HzwMz0JGAcYRco1t yhfK+QrfPYrYVBlIv81X8sn0LPA=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=JImoTfPOpVCcWJ9Y5Sb2Zz8YypVGE7Rjpq0Poo rMmup/ZuVmgI6ObrPnnjowP4PATFogmfm95Ww3F1whJzG8iSVAlaX3A1x5awU4CQ/JXF0e 71Slzyq4ZU1locVzrhNy49UkvBy9E80hIzg/8dMCXB1Jec199AAzyX5bEu/fb2yD92Ez7y EaCMQN8Si8Qu+FvwtWT41vTRhGjII2wbZJJ3p6FSrPfIHtWdqiuUyczUpmu1l/ib5ourfU OSaSpWDFwECnvaFStvkvHaSWZnc1ZTroyX/9dMf3n354eaSYAULDrTZqmn72e41r3hhv9c R93TWX8yguxVvHmHY2RvsUsQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 21f23e6f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 1 Nov 2023 20:55:39 +0100 (CET) From: Manuel Giraud In-Reply-To: <83r0l98e6w.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 Nov 2023 21:29:43 +0200") 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> <83r0l98e6w.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 01 Nov 2023 20:55:37 +0100 Message-ID: <87lebhckp2.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> 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. 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 From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2023 05:50:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169890414211554 (code B ref 63311); Thu, 02 Nov 2023 05:50:02 +0000 Received: (at 63311) by debbugs.gnu.org; 2 Nov 2023 05:49:02 +0000 Received: from localhost ([127.0.0.1]:53652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyQZh-00030B-RA for submit@debbugs.gnu.org; Thu, 02 Nov 2023 01:49:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyQZe-0002yw-1K for 63311@debbugs.gnu.org; Thu, 02 Nov 2023 01:49:00 -0400 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 1qyQYz-0006sP-2P; Thu, 02 Nov 2023 01:48:17 -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=szsI+e99wdpqAPKvDkiAkshsAxol6FmU0kEJUlCfSvE=; b=VSS0FcO9L4ns VIWOqCeyKIgWROhbdfljO9Mw3R6DbATDYb3QdeFw+bsJZVrycpOiVSF2ePcFSwiGdT+uAgCEBBn/F KLQwxKPhN3yZvMizPlyFXaf/xlwDqOFXqEMFHifPnf4w9EHvgEyEupph+JgdFbJJDvxYnug4+35je JCxv4f8TUQQY6qIxI4XYJxqg58Aa29X0B6TDtCZtW2C7XrW+VEvTzq4hiWauoMHHxFkFav0b5GJz8 BXbZfBW4Qi5tAiy+wQ+AZw4Zhd7KFExERSMsH8Sci/iE0U1UYmTaLiUmk9btlvwje3/LPF8duWYHG dce+4LGG8OiXjIxXEfOmyw==; Date: Thu, 02 Nov 2023 07:48:08 +0200 Message-Id: <83msvw904n.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87lebhckp2.fsf@ledu-giraud.fr> (message from Manuel Giraud on Wed, 01 Nov 2023 20:55:37 +0100) 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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Wed, 01 Nov 2023 20:55:37 +0100 > > Eli Zaretskii 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. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2023 10:46: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169892192117633 (code B ref 63311); Thu, 02 Nov 2023 10:46:01 +0000 Received: (at 63311) by debbugs.gnu.org; 2 Nov 2023 10:45:21 +0000 Received: from localhost ([127.0.0.1]:54001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyVCT-0004aL-Fk for submit@debbugs.gnu.org; Thu, 02 Nov 2023 06:45:21 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:46100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyVCQ-0004aA-LZ for 63311@debbugs.gnu.org; Thu, 02 Nov 2023 06:45:20 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=1317ypzy Pp5fLjcyJx4Lno7QPzYCaMNKZ5twoHoXf7M=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=ZEoOYnSkVlOHZGDAagv5JrcB/MR7Lw 62t4YUa8rYEAhKxyjEwjb1lv4db2/IJDoRH15Ps0mUVVuIpbNoxmcoBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=1317ypzyPp5fLjcy Jx4Lno7QPzYCaMNKZ5twoHoXf7M=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=FXpOOyEVYx9lYgbq6FZJZVaMKNAQLVaD1ZyPCY HBWHpAGGQcWf/NPhgKNDmCDotJiE6xF2kbNKAZ7ZXz9THmtH5LoVEgTVVc+0dWQ6XmOzVb CuEQry6km339wGh/rLV9GaNPIdtzcLDDoqhaJySNkhOAfbcrhYHq97pCd+i3TSzRiiy26q RRUkulBhQ3pSp8HK+J7hmHjZN/fv+IK4mAGwkuM5m+pcPY+k7H6ebDYhbDJswt+LqraBCy d6nPc7BrHc95TIOKnHAk/BDDwEQEpfGB7fHg6p5Iky+ffgdg215BfOwPHnLtehiEsVWx3S UQzTEU/nRXI6i4uXvzsH7hsw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id c41d7d45 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 2 Nov 2023 11:44:41 +0100 (CET) From: Manuel Giraud In-Reply-To: <83msvw904n.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Nov 2023 07:48:08 +0200") 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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 02 Nov 2023 11:44:40 +0100 Message-ID: <87wmv0zb6v.fsf@ledu-giraud.fr> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] > 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. I think this is feasible for the message when the thread is launch but not for the final message: the main-thread would have to 'thread-join' on the sending thread and we'll lose the asynchronous behaviour, no? > 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. Ok. [...] > 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. Yes, I think it should be opt-in. But such an option will also have ramifications in message.el, Gnus and surely more that I don't even know about. (BTW, do you have an idea for a name for such option?) -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2023 11:27:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169892442022237 (code B ref 63311); Thu, 02 Nov 2023 11:27:02 +0000 Received: (at 63311) by debbugs.gnu.org; 2 Nov 2023 11:27:00 +0000 Received: from localhost ([127.0.0.1]:54049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyVqi-0005mW-Nm for submit@debbugs.gnu.org; Thu, 02 Nov 2023 07:27:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyVqc-0005mC-Nd for 63311@debbugs.gnu.org; Thu, 02 Nov 2023 07:26:55 -0400 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 1qyVpx-0003Qc-PA; Thu, 02 Nov 2023 07:26:10 -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=hX9P787C/tJxLGYnSWFB8AEOIYGpsFwDu/pUvlC893o=; b=HTDph/E6ill1 NJkLWk+g6oyOgjwHYJOLG0XX0L30A3WjtOrfFjH1CyLq0G1bB9OSbMHxr1FEKu+qvnTZ1vLWP5Z8r p93OdposBIMJCgpu2oWcjPTYBmccXd7mdl+Kqn1H5NA2rVQL1s+XsFjhzlbQBC63DO5eDh79O5ncV F+B00zXOA0pVnO4VzT7r0wBgeNSCyhjvMMt9+qTvXTzl2FFU6EJyI0juQzVMBwLio/ucChrhauuiW BVQVYVst8tULFdo7T4t9/92GscPxnF3rKKmOicteigix9khoPDuznmn6Rz564rlGolWi807Elh59B ZZhuXcMY3/hROdSnY9T/RQ==; Date: Thu, 02 Nov 2023 13:26:02 +0200 Message-Id: <8334xo8khh.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wmv0zb6v.fsf@ledu-giraud.fr> (message from Manuel Giraud on Thu, 02 Nov 2023 11:44:40 +0100) 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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Thu, 02 Nov 2023 11:44:40 +0100 > > Eli Zaretskii writes: > > [...] > > > 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. > > I think this is feasible for the message when the thread is launch but > not for the final message: the main-thread would have to 'thread-join' > on the sending thread and we'll lose the asynchronous behaviour, no? That is not necessary. The background thread could add the message to some queue which the main thread could check from time to time. Or something similar. > > 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. > > Yes, I think it should be opt-in. But such an option will also have > ramifications in message.el, Gnus and surely more that I don't even know > about. Probably. (Another client is sendmail.el.) > (BTW, do you have an idea for a name for such option?) smtpmail-send-message-in-background ? From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 02:33: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 To: Manuel Giraud Cc: eliz@gnu.org, 63311@debbugs.gnu.org Reply-To: rms@gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16989787508493 (code B ref 63311); Fri, 03 Nov 2023 02:33:01 +0000 Received: (at 63311) by debbugs.gnu.org; 3 Nov 2023 02:32:30 +0000 Received: from localhost ([127.0.0.1]:56530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyjyz-0002Cr-Qs for submit@debbugs.gnu.org; Thu, 02 Nov 2023 22:32:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyjyu-0002Ca-Mf for 63311@debbugs.gnu.org; Thu, 02 Nov 2023 22:32:25 -0400 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 1qyjyF-0006Zo-6Q; Thu, 02 Nov 2023 22:31:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=+CqikK+DksrNaaqEsbL+IsYSEcpAC94Gw5q7wGZExyk=; b=NDHdYsRHt1eT 5pidEh9LMldjbALuxwMTG9EfomvjCROwNOKsZZHl/YIWvzgyKF/TLEBrd+yKGgd+Dl2hHy/m/eyBx qn7yngfLHIlwPgvWe+iogM8IK8wjx4tfpDBA/MZaGLOjM6PMAPCJiW2gy2dsagQMIjmhQQQSvJNew zx7B83e2L/9sNCchSkp72ooNigboJy29PC2VwfU935zvQEfPoCHogxlsxz9bDc0jGR5e4lMie8ZvM loi6PKuXGjpR3VD9rXnQmhlDYWqc3Ggz/hMTorb4jCUzw1n+JBAYTynwgXhEO3VBwpq7D7RTi9bNo K0F6G++7Vms9imRB7rNhYQ==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qyjyB-0003e1-BI; Thu, 02 Nov 2023 22:31:36 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-Reply-To: <87bkcde4bz.fsf@ledu-giraud.fr> (bug-gnu-emacs@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> Message-Id: Date: Thu, 02 Nov 2023 22:31:35 -0400 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > The progress and "Sending email done" still shows in echo-area and > *Messages* buffer but asynchronously. I think that may prove confusing. What happens if you send a message, then edit the buffer and send again before that "done" message appears for the first? When the "done" message appears, can you tell which message was sent? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 07:21: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 To: rms@gnu.org Cc: 63311@debbugs.gnu.org, manuel@ledu-giraud.fr Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16989960074841 (code B ref 63311); Fri, 03 Nov 2023 07:21:01 +0000 Received: (at 63311) by debbugs.gnu.org; 3 Nov 2023 07:20:07 +0000 Received: from localhost ([127.0.0.1]:56666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyoTL-0001Fx-QX for submit@debbugs.gnu.org; Fri, 03 Nov 2023 03:20:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyoTH-0001FL-5y for 63311@debbugs.gnu.org; Fri, 03 Nov 2023 03:20:02 -0400 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 1qyoSb-0008P8-Nm; Fri, 03 Nov 2023 03:19:17 -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=7AgdPWG6I040xmB8tlsaxvYUOhW3YOMGKVzzDZChvZY=; b=PRr2kuSGE/G/ oPS8h/MlvTFMYqOCvR/dCjpSRegShiH3O4Mzib5z1BZl5VDTdXL8uU02idVfRt8MigUW/KJ5OasnU bB/42jLdK4YazpbycZZq0fR13tHBYKKAMEve/YGDmSKknT1pX15M43DkxjfUc0f0p1lAy6eisQPSC cNGqMjk0bPwWGQCnjIW2IRSKYdiU6M59IQzimK48eB1AxR+YJiJdFFI4ubIz/vtNmQSJa8Dr3ikQb ZwnX9y1PEuJYfjA1MU1rvGGdD43WlgnSFCm4iLhPYtPn6P5T+ZzDNNxCy9EfbQoFrIlsTwUXq6xyP ykVzoi8WxS1umLHEcoJ5HA==; Date: Fri, 03 Nov 2023 09:18:54 +0200 Message-Id: <83o7gb719d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Richard Stallman on Thu, 02 Nov 2023 22:31:35 -0400) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Cc: eliz@gnu.org, 63311@debbugs.gnu.org > Date: Thu, 02 Nov 2023 22:31:35 -0400 > > > The progress and "Sending email done" still shows in echo-area and > > *Messages* buffer but asynchronously. > > I think that may prove confusing. What happens if you send a message, > then edit the buffer and send again before that "done" message appears > for the first? When the "done" message appears, can you tell which message > was sent? The messages should be displayed by the main thread when the sending thread finishes sending. And we probably need to rethink the text of the messages, to identify the message that was sent. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 13:51: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 To: Eli Zaretskii Cc: rms@gnu.org, 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169901942210979 (code B ref 63311); Fri, 03 Nov 2023 13:51:01 +0000 Received: (at 63311) by debbugs.gnu.org; 3 Nov 2023 13:50:22 +0000 Received: from localhost ([127.0.0.1]:57319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyuZ4-0002r1-Dr for submit@debbugs.gnu.org; Fri, 03 Nov 2023 09:50:22 -0400 Received: from ledu-giraud.fr ([51.159.28.247]:9558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyuZ1-0002qr-Sq for 63311@debbugs.gnu.org; Fri, 03 Nov 2023 09:50:21 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=/q63oj1D 56po957i+elDzBNGJPWP8TCup368OdT0HZc=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=epWrPPlyOXG0N0kiiU2AWgBQZBQoDv 7ez6CM5XsZbE9Hr6TPgFm3dfW65FGXb/b4BMQM1ZcDkK/YPEbqgfuTDg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=/q63oj1D56po957i +elDzBNGJPWP8TCup368OdT0HZc=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=sKtKQjoKWeW3m7ZepQ8kQcedlmlxaoa73CO2j1 EQ3YH218GSrXyES4SkTJu4xbMwT1+Z0tdieLoKC+xnOhxcibSrDoZctjCjk2AgUNatiW02 UR/4T30khk4nX5RK2DD3D+jdFy+Rj42ZilyBIt3iL4S8v5NvPCHQsS2KOBwIj/+RpnthQt Uleq4AYrszN+8Yx93igkkVnUaLVV7PKlV5DfI9LSuFu6TY6dPaGE5LdOAGoGvqW20V3jrT OZiJ+U3xoEK1trdXDL+I4QD2xFvBhkA+M6VDKllCuFEu715+JDnfQsd3t6Bcd6UF05CUmO vS0XT5oWkuXbyHNBQw6OhIaQ== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id dba91800 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 3 Nov 2023 14:49:42 +0100 (CET) From: Manuel Giraud In-Reply-To: <83o7gb719d.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Nov 2023 09:18:54 +0200") 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> <83o7gb719d.fsf@gnu.org> Date: Fri, 03 Nov 2023 14:49:40 +0100 Message-ID: <87wmuzymiz.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Richard Stallman >> Cc: eliz@gnu.org, 63311@debbugs.gnu.org >> Date: Thu, 02 Nov 2023 22:31:35 -0400 >> >> > The progress and "Sending email done" still shows in echo-area and >> > *Messages* buffer but asynchronously. >> >> I think that may prove confusing. What happens if you send a message, >> then edit the buffer and send again before that "done" message appears >> for the first? When the "done" message appears, can you tell which message >> was sent? > > The messages should be displayed by the main thread when the sending > thread finishes sending. And we probably need to rethink the text of > the messages, to identify the message that was sent. Yes, of course. But I think we could do that at the very end of this work. -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Nov 2023 14: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 To: Manuel Giraud Cc: rms@gnu.org, 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169902181416915 (code B ref 63311); Fri, 03 Nov 2023 14:31:01 +0000 Received: (at 63311) by debbugs.gnu.org; 3 Nov 2023 14:30:14 +0000 Received: from localhost ([127.0.0.1]:59495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyvBe-0004Ol-Dm for submit@debbugs.gnu.org; Fri, 03 Nov 2023 10:30:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyvBc-0004OT-9Z for 63311@debbugs.gnu.org; Fri, 03 Nov 2023 10:30:13 -0400 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 1qyvAx-0004rq-5R; Fri, 03 Nov 2023 10:29:31 -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=d07mBWu2kVR0CId1tUaoaQOcf4UVAy4pjyw6MzOCwm0=; b=T2+0UW8go/aR miwonXfreYxp6dAvRMa1E1w6My24gR3EjlXXOV+Y9pT7p6b13vkaiP1t71TCmwsda/h/Q3nIN0jTm 3oBPFREbzXXfSGKJmZCq9WaObudHXoFbBSrV49tL/jru+7+HIMHFSf98BUdhw7HZitPxccEubd5Ma IoBxT9xl7uZ8RTIlbQckJaiEcriF7Au1lZugT8jQ+LRI0tCvXXE09rl4NyflqNeREOHiJaUYUN1j5 uXlRoWCNwrnMTh7L6FAwIf3Uo3O1X9xMb5cmcMAa2raVxHCn8ZSXY7r7GAs5iThT4z7/ZMvpNwr/e kqtUZcApg22FyRVY0yKCYg==; Date: Fri, 03 Nov 2023 16:29:02 +0200 Message-Id: <838r7e7vwx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wmuzymiz.fsf@ledu-giraud.fr> (message from Manuel Giraud on Fri, 03 Nov 2023 14:49:40 +0100) 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> <83o7gb719d.fsf@gnu.org> <87wmuzymiz.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: rms@gnu.org, 63311@debbugs.gnu.org > Date: Fri, 03 Nov 2023 14:49:40 +0100 > > Eli Zaretskii writes: > > > The messages should be displayed by the main thread when the sending > > thread finishes sending. And we probably need to rethink the text of > > the messages, to identify the message that was sent. > > Yes, of course. But I think we could do that at the very end of this > work. Agreed. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2023 14:26:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16991943347341 (code B ref 63311); Sun, 05 Nov 2023 14:26:02 +0000 Received: (at 63311) by debbugs.gnu.org; 5 Nov 2023 14:25:34 +0000 Received: from localhost ([127.0.0.1]:36378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qze4E-0001uL-D0 for submit@debbugs.gnu.org; Sun, 05 Nov 2023 09:25:34 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:44212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qze4B-0001u6-RX for 63311@debbugs.gnu.org; Sun, 05 Nov 2023 09:25:33 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=X7qPc6xO KnpDUuqiTWwd1zg57NNjnCVzkbIxGKpR76o=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=Ses81R6auRmDRdPxkIXiFXcSlaXNyh YvL8hRetvu5yPt2UgfvlUoyJ8OBslIZgMLM3m41RbvHHHcSkh6DJiBAw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=X7qPc6xOKnpDUuqi TWwd1zg57NNjnCVzkbIxGKpR76o=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=PHuKQN3NcrZFnw/A+2g86bvS6bM3gbA6hGO3wz ZdyPUPODOTv7v92fCwE7LTSAaF2K6d05NWbsIvcgC/dgGY6eH2nDMyWv+RHOorI4qzojRo pGbFTx/XDPBYoM7oI4k2xGDNAlMOlzb29FxopG6Xh+z+b0u4uRKSNcBXu91jeKldWQH3Sn azxYzuuaI5batGJ2t4xRMwpUsynqYuvm6DRr/OXyhQwjgdOwgHhQZfywr4BF7ITb+D12Gc bgfqWxDBh3wPposPdh/irxr70SMhbF4GIphREzcrAQRTT0Aqg/Wybv1yNQRSaQsmEWx+i5 Ypxi/p7ADA/H7pGMoWfEMa8g== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 2f5ff027 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 5 Nov 2023 15:24:53 +0100 (CET) From: Manuel Giraud In-Reply-To: <8334xo8khh.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Nov 2023 13:26:02 +0200") 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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> Date: Sun, 05 Nov 2023 15:24:50 +0100 Message-ID: <87ttq0nuq5.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli, I'm still struggling with making 'smtpmail-send-it' async. As I'm using message.el, I'm trying to make it work here. But message.el in written in such way that it is quite hard to make it work with a threaded 'smtpmail-send-it' call. And then, from a message buffer (with a quite large attachment), I've just evaluted the following: (make-thread #'message-send)... and everything went ok: - Emacs is still responsive: I could switch to other buffers, request the status of a VC handled file. - When the message is finally sent, the buffer is renamed accordingly and tagged as sent via mail. So my question is this one: instead of making 'smtpmail-send-it' threaded why not have a threaded version of toplevel commands (such as 'message-send')? We could hopefully do the same for sendmail.el. Of course, we should have it as opt-in behind customs (message-send-in-background and/or mail-send-in-background?) As for when something goes wrong and we end up in an 'error' call, maybe we should fix how 'error' behave inside a thread. What am I missing? -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2023 15:48: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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169919926226970 (code B ref 63311); Sun, 05 Nov 2023 15:48:01 +0000 Received: (at 63311) by debbugs.gnu.org; 5 Nov 2023 15:47:42 +0000 Received: from localhost ([127.0.0.1]:38029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzfLi-00070w-Fj for submit@debbugs.gnu.org; Sun, 05 Nov 2023 10:47:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzfLg-00070g-7C for 63311@debbugs.gnu.org; Sun, 05 Nov 2023 10:47:41 -0500 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 1qzfKz-0006dZ-Dc; Sun, 05 Nov 2023 10:46:57 -0500 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=9T0wNSidOMr5qIghXnFsNsnqfRTN4OAVd43zLNSWFFo=; b=D22PaDjqK6U9 R74NMtztrQDY/V2MFPP5NfgxlfiR0g2QdRZp//7wsQjoGvl6LVN0lGZ+ULsOhvFrABT/sJYfBvlJq Frs89x82Xhjz9ZGFr6nSfTUuDXv4mVjR9arz1/0JdXBcjaRI3i0jyFJLXv6u6b0fJr1z0bj4Fkp07 lgi3pW/20z0psZbEgJ46hleHgahn830QLkH6b1HESHH3WpZh1DmQ5awdrYfj7TZWOc4hvombLhhP+ hqYUOS6i7oLfTuA1D7y2JZNJMpdgApqhSvc/KyVw0d4NyAOo7v+YXsyyiQ7gwZbf6Ea7mkj2+ts6j uLj1bUn9X3I8YrgUsQ0ZNg==; Date: Sun, 05 Nov 2023 17:46:40 +0200 Message-Id: <835y2g42zj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ttq0nuq5.fsf@ledu-giraud.fr> (message from Manuel Giraud on Sun, 05 Nov 2023 15:24:50 +0100) 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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Sun, 05 Nov 2023 15:24:50 +0100 > > Hi Eli, > > I'm still struggling with making 'smtpmail-send-it' async. As I'm using > message.el, I'm trying to make it work here. But message.el in written > in such way that it is quite hard to make it work with a threaded > 'smtpmail-send-it' call. > > And then, from a message buffer (with a quite large attachment), I've > just evaluted the following: (make-thread #'message-send)... and > everything went ok: > - Emacs is still responsive: I could switch to other > buffers, request the status of a VC handled file. > > - When the message is finally sent, the buffer is renamed > accordingly and tagged as sent via mail. > > So my question is this one: instead of making 'smtpmail-send-it' > threaded why not have a threaded version of toplevel commands (such as > 'message-send')? We could hopefully do the same for sendmail.el. Of > course, we should have it as opt-in behind customs > (message-send-in-background and/or mail-send-in-background?) > > As for when something goes wrong and we end up in an 'error' call, maybe > we should fix how 'error' behave inside a thread. What am I missing? Nothing, AFAIU. Instead of making smtpmail-send-it optionally working asynchronously, it should be perfectly valid to have a separate function called, say, message-send-asynchronously, which would work with background threads and implement the same protocol as the other MUA's send-it functions do. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2023 16:13: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169920077029970 (code B ref 63311); Sun, 05 Nov 2023 16:13:01 +0000 Received: (at 63311) by debbugs.gnu.org; 5 Nov 2023 16:12:50 +0000 Received: from localhost ([127.0.0.1]:38046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzfk2-0007nK-JG for submit@debbugs.gnu.org; Sun, 05 Nov 2023 11:12:50 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:15710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzfjz-0007n4-DW for 63311@debbugs.gnu.org; Sun, 05 Nov 2023 11:12:48 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=duespICh MTrqd5D6AgWvdm4NdHC5hAUUMZfR58ODCRo=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=+LlY6qv7uvCHH/ys9J84tu3gshyIRf QglSO11jrPME7Zvf/aNZNCAVgNoQtElHoECLtThY18ocHk/3se/ubEBw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=duespIChMTrqd5D6 AgWvdm4NdHC5hAUUMZfR58ODCRo=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=lbCCf9CZ8ndSFT3Ydn8pIzcyXIJ+zdWSCSEq8Y wAhb9odm0HIoB09C+iS7oPdQ3wwwFb7nbO/fLjFsqaomIJW9PwbUW3LwtNuBBcGGg1TS4E ujvjdtS4rPOIzfKvmbj6X/+umtF1yNc5Yze5YO2l8oC7I+t+2FM6nU2RhulFwOsZQQLiUK RoV7NM5yQuc7qlgCMHViGscLupOOY1zg5C+s6/TRRGBmryTrd9vJBBTDKVK0CiB1H/kyoh tJfMQoQEVCoce6mlLM1OxVRU1j/dqQPBWhwcFFQ90TqnPE1gMQUVmFzXKma0o8Cqv3tcCE XUN3GYIbLkHWdOuPJOaS7Gxw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id bd2aebb2 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 5 Nov 2023 17:12:05 +0100 (CET) From: Manuel Giraud In-Reply-To: <835y2g42zj.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Nov 2023 17:46:40 +0200") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> Date: Sun, 05 Nov 2023 17:12:03 +0100 Message-ID: <87msvsfacs.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] >> As for when something goes wrong and we end up in an 'error' call, maybe >> we should fix how 'error' behave inside a thread. What am I missing? > > Nothing, AFAIU. Instead of making smtpmail-send-it optionally working > asynchronously, it should be perfectly valid to have a separate > function called, say, message-send-asynchronously, which would work > with background threads and implement the same protocol as the other > MUA's send-it functions do. Ok. But there is still the case where any 'error' call from a thread will end up in limbo, no? -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Nov 2023 16:19: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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169920113330624 (code B ref 63311); Sun, 05 Nov 2023 16:19:01 +0000 Received: (at 63311) by debbugs.gnu.org; 5 Nov 2023 16:18:53 +0000 Received: from localhost ([127.0.0.1]:38051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzfpt-0007xr-F3 for submit@debbugs.gnu.org; Sun, 05 Nov 2023 11:18:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzfpr-0007xc-NA for 63311@debbugs.gnu.org; Sun, 05 Nov 2023 11:18:52 -0500 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 1qzfpB-0003jD-C4; Sun, 05 Nov 2023 11:18:09 -0500 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=vfpsNEJ2CRDxM0KVLu9AfYMWIBCXkiHBOXa9Nbm+c0Q=; b=FqaudYOaV5ot NwTUfXYjok+bnnxUdM9/YwqDzgAZ9RGYVOFZFQOuc/wM1rej3bW6gEYYnhJW/LbuBa+MNJZTi9jDv 7PU0WXYy+sldNBPdCW7+kAWHKgQXU1DH39PvtRQKyEOgtSkHEYor+Xk2tRm2TGP9Zgz2IZSyPGSHR xMZ/9Y1I3/b8fMW+SyAU17QYG9GrqERNgW01R7F1z+5ijjh99YDbVYfozG69Q0xAfMXbGBXut6dBz uZJwL12Vc3MDhkpu7sD3p/u9kzeMufg8OsuQXH0B5/LlU7OYblkRzEELr6xuvU9pDSQkewzSk4E58 ZWOpjIUNRsqInb1Kao2VbQ==; Date: Sun, 05 Nov 2023 18:17:52 +0200 Message-Id: <834ji041jj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87msvsfacs.fsf@ledu-giraud.fr> (message from Manuel Giraud on Sun, 05 Nov 2023 17:12:03 +0100) References: <87jzxmsyyr.fsf@ledu-giraud.fr> <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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Sun, 05 Nov 2023 17:12:03 +0100 > > Eli Zaretskii writes: > > > Nothing, AFAIU. Instead of making smtpmail-send-it optionally working > > asynchronously, it should be perfectly valid to have a separate > > function called, say, message-send-asynchronously, which would work > > with background threads and implement the same protocol as the other > > MUA's send-it functions do. > > Ok. But there is still the case where any 'error' call from a thread > will end up in limbo, no? The caller will need to fetch it and display it. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 10:23: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169926612611656 (code B ref 63311); Mon, 06 Nov 2023 10:23:01 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 10:22:06 +0000 Received: from localhost ([127.0.0.1]:38663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzwkA-00031w-0c for submit@debbugs.gnu.org; Mon, 06 Nov 2023 05:22:06 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:27732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzwk7-00031n-Q2 for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 05:22:05 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=kHjXHgyK /rDovgYEr7Oco1hz2zljyqmcippKAWZIhy0=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=/gJtz/lDr4D1NI+ehmZlMLjjEw+VAg B1bK5cY0ItwO/ONIgPX/Ti7TF2Ypgy0//Xc8TRPDN7cESLMOn3Ym0pDw== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=kHjXHgyK/rDovgYE r7Oco1hz2zljyqmcippKAWZIhy0=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=y/KyIrMAKCWJahXDPzDacTvhU3QtPD3fzyfs/7 0cOLyvUHIsivr04jNqnQAYNml8zgPY6VgHkHZe2EuPgKaYuFi/rFvSh14xRXHgCPtvfzdm scL52wIKRmuh60e9XcLLbYjahGdzgYg75qU0k+tdSgtRgoKEZLl70ZBHrEJ4dpDuBUfKmG ToZT897s9u9TdjBHuX3lYieZAd7vaZzn//pVt3nFLrKTSKAtx0BApKf/1vc7t5dG3gu98m bOWGzA+hwBGDruOPChb7mt6FXYGGcX+szdmjVLq2hiYFXORiPwKx1X7t3Wx5iSkWZYVNgB QOHgkI0lbcHsnCd2opDvWlYg== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 916d1065 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 6 Nov 2023 11:21:24 +0100 (CET) From: Manuel Giraud In-Reply-To: <834ji041jj.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 Nov 2023 18:17:52 +0200") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> Date: Mon, 06 Nov 2023 11:21:23 +0100 Message-ID: <87zfzrfaho.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 63311@debbugs.gnu.org >> Date: Sun, 05 Nov 2023 17:12:03 +0100 >> >> Eli Zaretskii writes: >> >> > Nothing, AFAIU. Instead of making smtpmail-send-it optionally working >> > asynchronously, it should be perfectly valid to have a separate >> > function called, say, message-send-asynchronously, which would work >> > with background threads and implement the same protocol as the other >> > MUA's send-it functions do. >> >> Ok. But there is still the case where any 'error' call from a thread >> will end up in limbo, no? > > The caller will need to fetch it and display it. Yes but how would I do that. My idea was to left much code unmodified (with all 'error' calls in case something goes wrong). But how the 'main-thread' could fetch these errors. -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 12:42:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16992744823776 (code B ref 63311); Mon, 06 Nov 2023 12:42:02 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 12:41:22 +0000 Received: from localhost ([127.0.0.1]:38856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzyuw-0000yo-4A for submit@debbugs.gnu.org; Mon, 06 Nov 2023 07:41:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qzyut-0000yZ-GS for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 07:41:20 -0500 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 1qzyuB-00015T-V3; Mon, 06 Nov 2023 07:40:36 -0500 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=lC7PTj0xOsssP7QOEirkq+1f6U6A6fYNx633Z+1lMcY=; b=Liflu0s95CwU OddzYeGi7wDZbLG39QC8I3dp4Z+xycqtSvlfzLzhVP+4SZpBXXIPwvBgPEY6i6AuTFyNHfBPptxwO j3K0N2G5Y0Q2r9Pp8R7BA3FzYfAmBUCOvpAFpBNDMmjvDX+cLaO2q59IKAiRg08pDiNU9CO01Pa8G bwZ6baviToPFnKN7VWWgQ2sMdxZGRJvoUAx5TaGaN19tVj6DjBkvtlSui2NTqC3bGiS8ZRPbFACsj x0Jab3U8oJKetwrKEPAzX7CmLEmaM4F2i8W69iAzjLzRnJRbBmNjiuK471Ju3mVCdx0A+yLO3pyg/ d5SF+Nug8fKtBNdd/ycQlQ==; Date: Mon, 06 Nov 2023 14:40:20 +0200 Message-Id: <83msvr2gy3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87zfzrfaho.fsf@ledu-giraud.fr> (message from Manuel Giraud on Mon, 06 Nov 2023 11:21:23 +0100) References: <87jzxmsyyr.fsf@ledu-giraud.fr> <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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Mon, 06 Nov 2023 11:21:23 +0100 > > Eli Zaretskii writes: > > >> Ok. But there is still the case where any 'error' call from a thread > >> will end up in limbo, no? > > > > The caller will need to fetch it and display it. > > Yes but how would I do that. My idea was to left much code unmodified > (with all 'error' calls in case something goes wrong). But how the > 'main-thread' could fetch these errors. Using thread-last-error, or at least that's what I had in mind. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 15:58: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16992862361730 (code B ref 63311); Mon, 06 Nov 2023 15:58:01 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 15:57:16 +0000 Received: from localhost ([127.0.0.1]:40412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r01yW-0000Rp-Gb for submit@debbugs.gnu.org; Mon, 06 Nov 2023 10:57:16 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:10751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r01yT-0000Rf-NS for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 10:57:15 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=xRGBYm9y z347Uw0+B8nai3jAsIK2RqVLEzkGxekFvIo=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=JpBM3CzAoTSWtKNSuW6QItci9ZTi6I ismwOsUA/s56KqsZbYIUF6b7/VqeLdg2K00A5fHLIu2p6zU3wI00qvAQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=xRGBYm9yz347Uw0+ B8nai3jAsIK2RqVLEzkGxekFvIo=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=eZs+00n4vAvOgZ7O1aHjF2t919MVCNRmp/49Nw 0v1Cobcw5LlUdoGn5yKJXBS2ebNED7RlYInBD5UDQ8fwI/KzuBXWvbeDpn+Z3OOvNlPYDO 3ZHjLUP2U3m9c1m/7uyLAQ5u7FWSIVLhgGe4a+TiWthD0u/cLguxJwi3J1ITwlGEru+KIg NJnIDeQydAUhj/jc4VOTzR/ZKTnqF0iSFMAAP7EHdZEekZCoABxwLox7YBZM2rv3NJSwUp KLShVU33cKAVPWkao1UldhgFX+9IC2fUvOC+DumQ98R2x2a9viCaQFKAi/JsA12a3jy9VH 0W/y9ufmYkSQvpbKKafExV9Q== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id e15819df (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 6 Nov 2023 16:56:34 +0100 (CET) From: Manuel Giraud In-Reply-To: <83msvr2gy3.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Nov 2023 14:40:20 +0200") References: <87jzxmsyyr.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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> Date: Mon, 06 Nov 2023 16:56:33 +0100 Message-ID: <87jzqux4cu.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 63311@debbugs.gnu.org >> Date: Mon, 06 Nov 2023 11:21:23 +0100 >> >> Eli Zaretskii writes: >> >> >> Ok. But there is still the case where any 'error' call from a thread >> >> will end up in limbo, no? >> > >> > The caller will need to fetch it and display it. >> >> Yes but how would I do that. My idea was to left much code unmodified >> (with all 'error' calls in case something goes wrong). But how the >> 'main-thread' could fetch these errors. > > Using thread-last-error, or at least that's what I had in mind. It seems that 'thread-last-error' is global for all threads of Emacs so I don't it would work. Doesn't a thread record its error status and message? -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 16:30:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16992881825283 (code B ref 63311); Mon, 06 Nov 2023 16:30:02 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 16:29:42 +0000 Received: from localhost ([127.0.0.1]:40448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r02Tt-0001N8-WD for submit@debbugs.gnu.org; Mon, 06 Nov 2023 11:29:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r02Ts-0001Mt-1w for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 11:29:40 -0500 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 1r02TA-00071b-Hk; Mon, 06 Nov 2023 11:28:56 -0500 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=raYVdY/5VY0fUdMKICQ0xFVUqzLJikQLNpnpdIfkXws=; b=Pgocp4RVCA2i a07u1pa6QJ/co5JfqqoO5Odnm8VC4OX4OjfPvoDFaZViUSGo7efqiIjYtEGpN21ZQruzKiI5kuBJu m9QqGF5jjF4c8M0EKJl4922o+pQCfRjaeh36TKRK5Lo7ywO9FZMI/rOHtKUjatvC26aAeszYJiq63 bJW42HwQmCyjQIu5J6y7tRVZ36fz67sR9d1TaNUBAkRUHblOYYZiI/6bpWoA3qFmDUUrdKpIOjvIM 0bklhlWkvS0wc63YPgEyhUpoSXWbxEGhW1ihGFzFZB4ebYScjQG6Gf0pW214vpo94TFNuBr9+iwU0 C1BruEXbWw5Wrtm9C9i8ew==; Date: Mon, 06 Nov 2023 18:28:41 +0200 Message-Id: <83fs1i3kxy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87jzqux4cu.fsf@ledu-giraud.fr> (message from Manuel Giraud on Mon, 06 Nov 2023 16:56:33 +0100) References: <87jzxmsyyr.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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Mon, 06 Nov 2023 16:56:33 +0100 > > Eli Zaretskii writes: > > >> Yes but how would I do that. My idea was to left much code unmodified > >> (with all 'error' calls in case something goes wrong). But how the > >> 'main-thread' could fetch these errors. > > > > Using thread-last-error, or at least that's what I had in mind. > > It seems that 'thread-last-error' is global for all threads of Emacs so > I don't it would work. Doesn't a thread record its error status and > message? Sorry, I don't understand what exactly you are asking and what you are saying. Yes, thread-last-error accesses a global storage, but I fail to see how this is a problem: if the main thread fetches the error in a timely fashion, it should still work. And if, for some reason, this is not good enough, we could come up with a more fine-grained mechanism. But first I'd like to see a description of a real problem with the existing mechanism: after all, it isn't expected that every single thread you launch will die due to an error, right? So the situation where a thread dies and we need to access its error should be relatively rare, and a global resource could still be adequate. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 17:59: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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169929352425760 (code B ref 63311); Mon, 06 Nov 2023 17:59:01 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 17:58:44 +0000 Received: from localhost ([127.0.0.1]:40677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r03s3-0006hQ-JQ for submit@debbugs.gnu.org; Mon, 06 Nov 2023 12:58:43 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:39117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r03s0-0006hE-9p for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 12:58:41 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=xtNDuPoN ZE6l602RPj+fFyjMuqAoOm+f1u/Wtsi1MDE=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=ATDrLWo/3vgQPSFBtndrbVFz/8mWN9 rUj2BLsdJ0Wf9XKCNOa2GqbFPewGtnaQo+HTRhx3AC8ts5wcnvlZkUAA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=xtNDuPoNZE6l602R Pj+fFyjMuqAoOm+f1u/Wtsi1MDE=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=fSmdkSbbd7DgYT56PXIOemuJ7XFhfXh+j5gEgh d6xbhj9YC6cPSskvR6DEhMLTXfWJFR+vyVlQGr2DIZoVNcTZDcOlPrqMRXtxUDyvBl9Ylf to5x730S1+j9geWm5vHIjPHxc4qBVLHNjC7aYd3VvaSot+qjQr3438O5Z4MdgkjM3Ym+tO 1QTGDn/NMzg99xHMOLBWaucQufnUBdAUJEZxxMMHW5WIwJuD6bM2k9x56aUQgiQHk2bPAT qpPxV6IbeVc0ljIL+x9xhJeeSOGWK+jfwvcCzaA84jph/BQYpmnqCnoF/+ID0R3kqAevaK nmEBqy+L5Mb6OUeWkvKWeXrw== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id c9c1273d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 6 Nov 2023 18:58:01 +0100 (CET) From: Manuel Giraud In-Reply-To: <83fs1i3kxy.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Nov 2023 18:28:41 +0200") References: <87jzxmsyyr.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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> Date: Mon, 06 Nov 2023 18:57:59 +0100 Message-ID: <87pm0mepco.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 63311@debbugs.gnu.org >> Date: Mon, 06 Nov 2023 16:56:33 +0100 >> >> Eli Zaretskii writes: >> >> >> Yes but how would I do that. My idea was to left much code unmodified >> >> (with all 'error' calls in case something goes wrong). But how the >> >> 'main-thread' could fetch these errors. >> > >> > Using thread-last-error, or at least that's what I had in mind. >> >> It seems that 'thread-last-error' is global for all threads of Emacs so >> I don't it would work. Doesn't a thread record its error status and >> message? > > Sorry, I don't understand what exactly you are asking and what you are > saying. > > Yes, thread-last-error accesses a global storage, but I fail to see > how this is a problem: if the main thread fetches the error in a > timely fashion, it should still work. And if, for some reason, this > is not good enough, we could come up with a more fine-grained > mechanism. But first I'd like to see a description of a real problem > with the existing mechanism: after all, it isn't expected that every > single thread you launch will die due to an error, right? So the > situation where a thread dies and we need to access its error should > be relatively rare, and a global resource could still be adequate. So just for recap, the idea is to have a command ('message-send-asynchronously' as you suggested) that will just be wrapper around 'message-send' and creates a thread to send the current buffer. Such a thread could be stored in a list and, by mean of a timer, the main-thread would sometimes look if this thread is dead. If it is dead and (thread-last-error) returns nil maybe we can conclude that everything went well. But if (thread-last-error) returns a message, it could be message from any other Emacs thread: what to do in such case? Or worse: the thread is dead, (thread-last-error) returns nil... but it was cleared from another part of Emacs. -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 19:23:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.16992985421299 (code B ref 63311); Mon, 06 Nov 2023 19:23:02 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 19:22:22 +0000 Received: from localhost ([127.0.0.1]:40711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r05B0-0000Ks-9i for submit@debbugs.gnu.org; Mon, 06 Nov 2023 14:22:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51530) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r05Ay-0000Kf-Co for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 14:22:21 -0500 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 1r05AH-0006o9-0u; Mon, 06 Nov 2023 14:21:37 -0500 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=pMz3j3LIYyYIue3zi1yNm4AMD0bU0TelKHbIphEcBi4=; b=akHfzqtEUhQh QJZbZpeJqCvmmdjCmT0AGQVg6jnrf9eIuZ6dwFYASMBRNI14qMpm7mEMka7HugoVGwnvUdiUBVpId lpYRHbvo8mLnzE0f52626x9XSHAlNzTFi2w2gldwX+L+4btmtzG1YjACVxBT8nohUJ5iqVymZ9hWn zPGv30V+iYfbuAIBQK1CWVt9RWtwed6xRcfo+3F/vE+o9ow7n0dWqEnh0U7KZSkaTDxPSsvB8gEw2 qIfXdM64fm23Cumy/x8jLE2fnM08XZUfBlzk1jrK6qxRC2/vTFyrvx4thBqIY2LqEJ9f4cf80yDKz uCyMRt/PQzAEJGTq7c+Piw==; Date: Mon, 06 Nov 2023 21:21:21 +0200 Message-Id: <838r7a3cy6.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87pm0mepco.fsf@ledu-giraud.fr> (message from Manuel Giraud on Mon, 06 Nov 2023 18:57:59 +0100) References: <87jzxmsyyr.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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Mon, 06 Nov 2023 18:57:59 +0100 > > So just for recap, the idea is to have a command > ('message-send-asynchronously' as you suggested) that will just be > wrapper around 'message-send' and creates a thread to send the current > buffer. Such a thread could be stored in a list and, by mean of a > timer, the main-thread would sometimes look if this thread is dead. Something like that, yes. > If it is dead and (thread-last-error) returns nil maybe we can conclude > that everything went well. But if (thread-last-error) returns a > message, it could be message from any other Emacs thread: what to do in > such case? Display a message about the error. > Or worse: the thread is dead, (thread-last-error) returns > nil... but it was cleared from another part of Emacs. This means it exited successfully. We could also maintain a data structure where successfully-exiting threads will leave their success status together with some id of the message they sent -- unlike a thread that dies abruptly due to an error, a successful thread can store the information in the data structure before exiting. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2023 20:57:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169930419310926 (code B ref 63311); Mon, 06 Nov 2023 20:57:02 +0000 Received: (at 63311) by debbugs.gnu.org; 6 Nov 2023 20:56:33 +0000 Received: from localhost ([127.0.0.1]:40780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r06e9-0002qA-AL for submit@debbugs.gnu.org; Mon, 06 Nov 2023 15:56:33 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:43267) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r06e6-0002q0-MI for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 15:56:32 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=4QlkQ/qk bukIqLLvXAItPOlU75kpJ53TCWwnJHge/is=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=iLyxpGQ2O1EQcppTF0iTgGgoA7LA2C Lk2SiLS9igutZSWAa5vymUxGqoKnFCqc5VqKHN5D8vHoKaR7iG5gSmDQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=4QlkQ/qkbukIqLLv XAItPOlU75kpJ53TCWwnJHge/is=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Vp890xgFFnwMxi0VlUXMuYqail4kRKB1SJgpxo 9MYI7W+BMPAkJNH/AdhD9gwTeZdQP1AxGLSTPkK+Te/0T06AroDEcF055VGbTkm612hg73 LKvKhnNkZOJEUmMawkVoHbH3SzDXW3IIo81A+QwzVVWiZu2XSY//1iiQBwhgDJFSWV/JX3 mnuYSxg1OLcUmotFmnjO4TcUZsky26TGHpuYa8y7XToghJmkqEVI+OXZR28YTbPKA1eLQ+ hOqcyGF2dGyT//kkSGvBs+L9qG0ZAKnkuSgzF4pvjFokWlwT6tBmntk7H2BuA+Ve9QraGe SgjGU9BD+SNybESO8v8AHySA== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id d2e439bb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 6 Nov 2023 21:55:51 +0100 (CET) From: Manuel Giraud In-Reply-To: <838r7a3cy6.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Nov 2023 21:21:21 +0200") References: <87jzxmsyyr.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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> <838r7a3cy6.fsf@gnu.org> Date: Mon, 06 Nov 2023 21:55:49 +0100 Message-ID: <87h6lyeh4a.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> If it is dead and (thread-last-error) returns nil maybe we can conclude >> that everything went well. But if (thread-last-error) returns a >> message, it could be message from any other Emacs thread: what to do in >> such case? > > Display a message about the error. I mean, the last error message could come from another thread not related in anyway to mail sending. No? >> Or worse: the thread is dead, (thread-last-error) returns >> nil... but it was cleared from another part of Emacs. > > This means it exited successfully. We could also maintain a data > structure where successfully-exiting threads will leave their success > status together with some id of the message they sent -- unlike a > thread that dies abruptly due to an error, a successful thread can > store the information in the data structure before exiting. Yes why not but then I'd have to modify internals of 'message-send': something I thought I could escape. -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 03:28: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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169932764029706 (code B ref 63311); Tue, 07 Nov 2023 03:28:01 +0000 Received: (at 63311) by debbugs.gnu.org; 7 Nov 2023 03:27:20 +0000 Received: from localhost ([127.0.0.1]:41064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0CkK-0007j3-C0 for submit@debbugs.gnu.org; Mon, 06 Nov 2023 22:27:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0CkI-0007iq-8g for 63311@debbugs.gnu.org; Mon, 06 Nov 2023 22:27:19 -0500 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 1r0Cja-0004nl-Vb; Mon, 06 Nov 2023 22:26:34 -0500 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=QExJBHmRVhy25UbFJfSWP/stxy9a7qoaLaQmrgj1sDo=; b=c0D8vlf9C/aR QXxvLWTaCafh9GVUCkJApJo0OcMf0lf6MknJ0/0PqjhT6epfkBblQuYb177DVxhC/Dc4MpKbd1WDH 6xzDxqBCBvc5ATr6ftKq0l5zVUKQEah3qQ51QSruZ6H8PMQbgDSEWN+h8cH2G00tVmifBTpLs5YhH KKx2GoOtZ9rY0S38JibB60LYxUgRlytjAaJKKcoxKcnDw5F5QskJEHesrwsAhvJ6xl6kSDX3YUT2a Hi7+ZmeUS1KScWsNnkK1qVpufW/ZT60UjAhzW7tgWLE5LieAhATbVDA1sIM8ELLHvpBwqQh1gcOT2 12JiEw7IoSrqyJO+YE/2/A==; Date: Tue, 07 Nov 2023 05:26:21 +0200 Message-Id: <837cmu2qhu.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87h6lyeh4a.fsf@ledu-giraud.fr> (message from Manuel Giraud on Mon, 06 Nov 2023 21:55:49 +0100) References: <87jzxmsyyr.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> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> <838r7a3cy6.fsf@gnu.org> <87h6lyeh4a.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Mon, 06 Nov 2023 21:55:49 +0100 > > Eli Zaretskii writes: > > >> If it is dead and (thread-last-error) returns nil maybe we can conclude > >> that everything went well. But if (thread-last-error) returns a > >> message, it could be message from any other Emacs thread: what to do in > >> such case? > > > > Display a message about the error. > > I mean, the last error message could come from another thread not > related in anyway to mail sending. No? It could, but why would there be other threads in this case? > >> Or worse: the thread is dead, (thread-last-error) returns > >> nil... but it was cleared from another part of Emacs. > > > > This means it exited successfully. We could also maintain a data > > structure where successfully-exiting threads will leave their success > > status together with some id of the message they sent -- unlike a > > thread that dies abruptly due to an error, a successful thread can > > store the information in the data structure before exiting. > > Yes why not but then I'd have to modify internals of 'message-send': > something I thought I could escape. I thought we were talking about a new function for this purpose, which would replace message-send, no? Then that new function could have this code. From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 09:08:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169934806210794 (code B ref 63311); Tue, 07 Nov 2023 09:08:02 +0000 Received: (at 63311) by debbugs.gnu.org; 7 Nov 2023 09:07:42 +0000 Received: from localhost ([127.0.0.1]:41299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0I3i-0002o1-4G for submit@debbugs.gnu.org; Tue, 07 Nov 2023 04:07:42 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:32853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0I3e-0002nq-M9 for 63311@debbugs.gnu.org; Tue, 07 Nov 2023 04:07:40 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=NfOXSqKW s/c+w9Wg1meL4qE+Teuy7txjonXtwXqw80w=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=+qgHhfFaEV5JkC7ug3g1zhqVdPkxtw Hdjcku8e/DFErapIAsFvm9Z+dcK92POfvrK9tJHXHQf+c6qIXAW2O0Dg== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=NfOXSqKWs/c+w9Wg 1meL4qE+Teuy7txjonXtwXqw80w=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=M7ag/WH86gs3G+aOlkyhBK6FJclm97vHxTtgv6 4dv4EH55a6SHboZuJ9caqR8y/Yk0h3wyYRUcjXkDphZQOz5IgWaM7VjPbi50KiEhl5rug0 WQc9iasnHG0/jCohdG68L4qu/MLE3SUXgjgAKWfJyfcB91MfG2IbtuEvJGuEnVnorZ1yzt yKNKx9Ehg8F5mxxRGmwwt7xm967x8/9Q1ESWCq/72rHo//qdI3PEcnrTSx2C9XGDUuYz4Q VjtmZJJoPR5Es1K1lSA+prnXcnytg8JW1ZnjWurg//VIPIeLDDBzJb7kBWTQ4DtQmkFW7t EKi7D6ylbAcdO7eG+nhOrm/A== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 6aaae193 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 7 Nov 2023 10:06:58 +0100 (CET) From: Manuel Giraud In-Reply-To: <837cmu2qhu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Nov 2023 05:26:21 +0200") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <87r0l9ejmm.fsf@ledu-giraud.fr> <834ji5aatw.fsf@gnu.org> <87bkcde4bz.fsf@ledu-giraud.fr> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> <838r7a3cy6.fsf@gnu.org> <87h6lyeh4a.fsf@ledu-giraud.fr> <837cmu2qhu.fsf@gnu.org> Date: Tue, 07 Nov 2023 10:06:58 +0100 Message-ID: <878r7adj9p.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: 63311@debbugs.gnu.org >> Date: Mon, 06 Nov 2023 21:55:49 +0100 >> >> Eli Zaretskii writes: >> >> >> If it is dead and (thread-last-error) returns nil maybe we can conclude >> >> that everything went well. But if (thread-last-error) returns a >> >> message, it could be message from any other Emacs thread: what to do in >> >> such case? >> > >> > Display a message about the error. >> >> I mean, the last error message could come from another thread not >> related in anyway to mail sending. No? > > It could, but why would there be other threads in this case? It seems that threads aren't used much in Emacs but isn't it dangerous to consider we're the only one using them? I don't if it would be easy but I think that it would be good to have a function like this: (thread-error thread) that would return the error message of the given thread like the global 'thread-last-error' does. >> >> Or worse: the thread is dead, (thread-last-error) returns >> >> nil... but it was cleared from another part of Emacs. >> > >> > This means it exited successfully. We could also maintain a data >> > structure where successfully-exiting threads will leave their success >> > status together with some id of the message they sent -- unlike a >> > thread that dies abruptly due to an error, a successful thread can >> > store the information in the data structure before exiting. >> >> Yes why not but then I'd have to modify internals of 'message-send': >> something I thought I could escape. > > I thought we were talking about a new function for this purpose, which > would replace message-send, no? Then that new function could have > this code. You're right it should be feasible inside this new function with something like that: --8<---------------cut here---------------start------------->8--- (make-thread #'(lambda () (if (message-send) (store-my-success) (store-my-failure)))) --8<---------------cut here---------------end--------------->8--- and then the main-thread will read those success or failure and act accordingly. -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 12:14:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169935919030967 (code B ref 63311); Tue, 07 Nov 2023 12:14:02 +0000 Received: (at 63311) by debbugs.gnu.org; 7 Nov 2023 12:13:10 +0000 Received: from localhost ([127.0.0.1]:41394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0KxB-00083P-MD for submit@debbugs.gnu.org; Tue, 07 Nov 2023 07:13:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Kx9-000834-7Q for 63311@debbugs.gnu.org; Tue, 07 Nov 2023 07:13:08 -0500 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 1r0KwR-0002FP-6W; Tue, 07 Nov 2023 07:12:23 -0500 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=IXWEgLq8XJeYF1Fz9DUOJ0AYVH8qe7ZU+k0IeTla/mM=; b=otOgXrpA8Vrm kIV4rNhSUZ3Q5r81BDguCenKw+JW8BvKBRgaTdfrFdTf4Kmj8OhHSzrpMjhwDBJvbHYaUqqg1jAjj 3Wsoq8VfsslAilhaepPXJN5SPUNBqB8jUylAMnjFvOiP1gYl0TWDIK1sxqxDZ+rUyq44BClAd/JWf j56soWjiONO0Hjy0DLVfeAYhVonL8UVv7OPT+0H9vBwuKuis/WttCqYVsasvgufND6BN52mIPuBZ8 tXcHE1d2RFobbG1EVIHHx3aXr0LhZyeDnnUKFAqvowGAoOqvRM+XhQihkHoTaSR2NUiN4GvTZdDwP gyUwgivI7NR67rIbknmlyg==; Date: Tue, 07 Nov 2023 14:12:11 +0200 Message-Id: <834jhx3gpw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878r7adj9p.fsf@ledu-giraud.fr> (message from Manuel Giraud on Tue, 07 Nov 2023 10:06:58 +0100) References: <87jzxmsyyr.fsf@ledu-giraud.fr> <87r0l9ejmm.fsf@ledu-giraud.fr> <834ji5aatw.fsf@gnu.org> <87bkcde4bz.fsf@ledu-giraud.fr> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> <838r7a3cy6.fsf@gnu.org> <87h6lyeh4a.fsf@ledu-giraud.fr> <837cmu2qhu.fsf@gnu.org> <878r7adj9p.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Tue, 07 Nov 2023 10:06:58 +0100 > > Eli Zaretskii writes: > > >> I mean, the last error message could come from another thread not > >> related in anyway to mail sending. No? > > > > It could, but why would there be other threads in this case? > > It seems that threads aren't used much in Emacs but isn't it dangerous > to consider we're the only one using them? I don't if it would be easy > but I think that it would be good to have a function like this: > > (thread-error thread) > > that would return the error message of the given thread like the global > 'thread-last-error' does. Maybe. But we decided not to add this until there's a real need for it. Also, threads don't really have a unique ID, at least not easily, so there's more here than meets the eye... From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 12:58:02 +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 To: Eli Zaretskii Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169936184213442 (code B ref 63311); Tue, 07 Nov 2023 12:58:02 +0000 Received: (at 63311) by debbugs.gnu.org; 7 Nov 2023 12:57:22 +0000 Received: from localhost ([127.0.0.1]:41444 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Ldx-0003Uj-L2 for submit@debbugs.gnu.org; Tue, 07 Nov 2023 07:57:21 -0500 Received: from ledu-giraud.fr ([51.159.28.247]:26166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Ldv-0003UY-3c for 63311@debbugs.gnu.org; Tue, 07 Nov 2023 07:57:20 -0500 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=Y6QYgjbA y5vKRkKneOMAbLlOEAesJHRSUpTJ+6tgrNs=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=k02GepAPfkhthdMPSwsE68ToUwpixi 4Q5dyO+ljqxUor7MXL4+iDjFM0KFjtbACldqGtIXN/ylR0bhEn/n9cDQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=Y6QYgjbAy5vKRkKn eOMAbLlOEAesJHRSUpTJ+6tgrNs=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=tfLmrPC8fz19C2ENDKDwyQLbAvy2/OAyvHoR2Q 2uHGChOJKMvZWmzeuHbuTmADq14D/iJbXT3bGVTdN9XA8FbXjpMeHlDBBJ13B0KcjVgLLN N/0ZLqOA8AlLjjuO6PdvicIym9Zpz3quxDVH9470UVQVCk7kEcgkELDKLPfag4gbYq2eK2 xwiJ1YrhyHBjYTi8VRTjf7NJZd+KJP8ftfS/QyqPkpnM79YsrrKIRw51UASHC/YBsUiGsN L9z5uEEpYnmWUz7NebDsh9jvUdLxwl8J/0VqQJiU4+OSe+ebfL6TTx3uqLCSqlBuP0cp5+ oSRUMyu0Vtgcd3k0MKvHOq1g== Received: from computer ( [10.1.1.1]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 5f65ddb5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 7 Nov 2023 13:56:39 +0100 (CET) From: Manuel Giraud In-Reply-To: <834jhx3gpw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Nov 2023 14:12:11 +0200") References: <87jzxmsyyr.fsf@ledu-giraud.fr> <87bkcde4bz.fsf@ledu-giraud.fr> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> <838r7a3cy6.fsf@gnu.org> <87h6lyeh4a.fsf@ledu-giraud.fr> <837cmu2qhu.fsf@gnu.org> <878r7adj9p.fsf@ledu-giraud.fr> <834jhx3gpw.fsf@gnu.org> Date: Tue, 07 Nov 2023 13:56:38 +0100 Message-ID: <87fs1hlo1l.fsf@ledu-giraud.fr> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: [...] >> that would return the error message of the given thread like the global >> 'thread-last-error' does. > > Maybe. But we decided not to add this until there's a real need for > it. Ok. > Also, threads don't really have a unique ID, at least not easily, > so there's more here than meets the eye... What do you mean by this? Where does this ID come from? -- Manuel Giraud From unknown Sun Jun 15 09:00:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#63311: 30.0.50; [PATCH] smtpmail-send-it split Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 13:19:02 +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 To: Manuel Giraud Cc: 63311@debbugs.gnu.org Received: via spool by 63311-submit@debbugs.gnu.org id=B63311.169936313415795 (code B ref 63311); Tue, 07 Nov 2023 13:19:02 +0000 Received: (at 63311) by debbugs.gnu.org; 7 Nov 2023 13:18:54 +0000 Received: from localhost ([127.0.0.1]:41468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Lyn-00046h-MS for submit@debbugs.gnu.org; Tue, 07 Nov 2023 08:18:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0Lyl-00046U-Hr for 63311@debbugs.gnu.org; Tue, 07 Nov 2023 08:18:52 -0500 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 1r0Ly2-0000QV-FE; Tue, 07 Nov 2023 08:18:07 -0500 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=guYxmpVO8cLRzHYxHhhIAEjBvhY9vlvLW5O4P1JzLWk=; b=c1JwtRV8tMhK O436kk9EH6En0hEYNoZpXtMA12e+AseePHdJIMJIGzHpo7izUtmB5YAPZtkOIXj5ryTju8+SZNbfY B3B/26W6tKNOqC6WEPPDoQm0/Z1eMlypdVtWlBUh79yJUNQV33xpvZfqoz1jsDocmTaWUCls6w0s6 o+xJ24IIS2FPtDmjjXl4UxslanmRwBJyxbOUM0ofWr2/E/giRhDB69QAawg4GswHmJetuwSAK7Ld+ 9fliv4l8KdfbLXuufXzzDoYsarkvgxETEtKUXqCTaw5bYYcfz1DZaOTibQ/HscVOmyDN3Fq53FM+j z8KUO1h3xGfMY3TV9qlUog==; Date: Tue, 07 Nov 2023 15:17:53 +0200 Message-Id: <83zfzp1z3y.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fs1hlo1l.fsf@ledu-giraud.fr> (message from Manuel Giraud on Tue, 07 Nov 2023 13:56:38 +0100) References: <87jzxmsyyr.fsf@ledu-giraud.fr> <87bkcde4bz.fsf@ledu-giraud.fr> <83r0l98e6w.fsf@gnu.org> <87lebhckp2.fsf@ledu-giraud.fr> <83msvw904n.fsf@gnu.org> <87wmv0zb6v.fsf@ledu-giraud.fr> <8334xo8khh.fsf@gnu.org> <87ttq0nuq5.fsf@ledu-giraud.fr> <835y2g42zj.fsf@gnu.org> <87msvsfacs.fsf@ledu-giraud.fr> <834ji041jj.fsf@gnu.org> <87zfzrfaho.fsf@ledu-giraud.fr> <83msvr2gy3.fsf@gnu.org> <87jzqux4cu.fsf@ledu-giraud.fr> <83fs1i3kxy.fsf@gnu.org> <87pm0mepco.fsf@ledu-giraud.fr> <838r7a3cy6.fsf@gnu.org> <87h6lyeh4a.fsf@ledu-giraud.fr> <837cmu2qhu.fsf@gnu.org> <878r7adj9p.fsf@ledu-giraud.fr> <834jhx3gpw.fsf@gnu.org> <87fs1hlo1l.fsf@ledu-giraud.fr> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Manuel Giraud > Cc: 63311@debbugs.gnu.org > Date: Tue, 07 Nov 2023 13:56:38 +0100 > > Eli Zaretskii writes: > > > Also, threads don't really have a unique ID, at least not easily, > > so there's more here than meets the eye... > > What do you mean by this? Where does this ID come from? >From the underlying threads library, I think.