From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 00:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 31052@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.152280205025302 (code B ref -1); Wed, 04 Apr 2018 00:35:01 +0000 Received: (at submit) by debbugs.gnu.org; 4 Apr 2018 00:34:10 +0000 Received: from localhost ([127.0.0.1]:37460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3WNN-0006a1-Lu for submit@debbugs.gnu.org; Tue, 03 Apr 2018 20:34:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3WNL-0006Zp-FR for submit@debbugs.gnu.org; Tue, 03 Apr 2018 20:34:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3WNF-00080s-1v for submit@debbugs.gnu.org; Tue, 03 Apr 2018 20:34:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35346) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f3WNE-00080n-UG for submit@debbugs.gnu.org; Tue, 03 Apr 2018 20:34:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3WND-0001ju-Dl for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 20:34:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3WNA-0007zK-AF for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 20:33:59 -0400 Received: from aibo.runbox.com ([91.220.196.211]:41200) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3WN9-0007yM-Sa for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 20:33:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=6kJKC4lh4GHRJKstGPZGO7wLnP+UBCuAEuPhOD7gB9Q=; b=npCFkMe9FJnZk0QN/PAhkSYKV D6SLZ4RblkiFq25vjBi1NFks3oTD6u7QFP//DgMoYWYLNdJ/zIx0cdw3ZcBNgrfz9mSBzy98mPlIi 1pO//kwSmZKnW1QRlzhZb5htxJ6wtdq9ZznVKI9LERkvFnOLFtCeJ9LzKl9BhkE+1YyZmZoeXXUyJ WvC1dVk3qbF2pEcaotgmMVP67beeEZcHtCZC9ljQOmR+z8po2dn0UJv7W+TjNtP2GE33G/zwtsD2h TPPPz01h28nXuuhKfS0U44g3xssg7vnzWs9B3hXZp/E4tUeHejzkAPK2392p4XF1/qu1FHx46SeN2 xFdLvSUew==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1f3WN8-0000fY-17 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 02:33:54 +0200 Received: from c-24-22-244-161.hsd1.wa.comcast.net ([24.22.244.161] helo=chinook) by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1f3WMu-0002hJ-B4 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 02:33:40 +0200 From: Gemini Lasswell Date: Tue, 03 Apr 2018 17:33:31 -0700 Message-ID: <87a7uj24kk.fsf@runbox.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) 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: -4.1 (----) --=-=-= Content-Type: text/plain I just got acquainted with inline-letevals and found its description in the Elisp manual confusing because the purpose of the macro is not stated, and it is described as similar to 'let' without mention of an important difference in what happens to the elements of the bindings list which are symbols. Here's a patch to functions.texi where I've attempted to clarify the description. --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=0001-Improve-documentation-of-inline-letevals.patch >From c1214913731b37c0444f8953a9b2a7619f22b2a9 Mon Sep 17 00:00:00 2001 From: Gemini Lasswell Date: Tue, 3 Apr 2018 13:12:15 -0700 Subject: [PATCH] Improve documentation of inline-letevals * doc/lispref/functions.texi (Defining Functions): Clarify what 'inline-letevals' is used for and how it differs from 'let'. --- doc/lispref/functions.texi | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi index 78372a8a10..a6187eb628 100644 --- a/doc/lispref/functions.texi +++ b/doc/lispref/functions.texi @@ -714,15 +714,19 @@ Defining Functions @end defmac @defmac inline-letevals (bindings@dots{}) body@dots{} -This is similar to @code{let} (@pxref{Local Variables}): it sets up -local variables as specified by @var{bindings}, and then evaluates -@var{body} with those bindings in effect. Each element of -@var{bindings} should be either a symbol or a list of the form -@w{@code{(@var{var} @var{expr})}}; the result is to evaluate -@var{expr} and bind @var{var} to the result. The tail of -@var{bindings} can be either @code{nil} or a symbol which should hold -a list of arguments, in which case each argument is evaluated, and the -symbol is bound to the resulting list. +Execute @var{body} in the context of @var{bindings}. This provides a +convenient way to ensure that the arguments to an inlined function are +evaluated exactly once, as well as to create local variables. Each +element of @var{bindings} should be either a symbol or a list of the +form @w{@code{(@var{var} @var{expr})}}. Elements of the form +@w{@code{(@var{var} @var{expr})}} work as in @code{let} (@pxref{Local +Variables}) to set up local variables by binding each symbol @var{var} +to the result of evaluating @var{expr}. When an element of +@var{bindings} is just a symbol @var{var}, the result of evaluating +@var{var} is re-bound to @var{var}. The tail of @var{bindings} can be +either @code{nil} or a symbol which should hold a list of arguments, +in which case each argument is evaluated, and the symbol is bound to +the resulting list. @end defmac @defmac inline-const-p expression -- 2.15.0 --=-=-=-- From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 06:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gemini Lasswell Cc: 31052@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.152282435225142 (code B ref 31052); Wed, 04 Apr 2018 06:46:01 +0000 Received: (at 31052) by debbugs.gnu.org; 4 Apr 2018 06:45:52 +0000 Received: from localhost ([127.0.0.1]:37543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3cB6-0006XS-3J for submit@debbugs.gnu.org; Wed, 04 Apr 2018 02:45:52 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3cB5-0006XG-1m for 31052@debbugs.gnu.org; Wed, 04 Apr 2018 02:45:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3cAu-00025C-Up for 31052@debbugs.gnu.org; Wed, 04 Apr 2018 02:45:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3cAu-00024z-RE; Wed, 04 Apr 2018 02:45:40 -0400 Received: from [176.228.60.248] (port=3617 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f3cAu-0003hp-DM; Wed, 04 Apr 2018 02:45:40 -0400 Date: Wed, 04 Apr 2018 09:45:50 +0300 Message-Id: <83efjv4ggx.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87a7uj24kk.fsf@runbox.com> (message from Gemini Lasswell on Tue, 03 Apr 2018 17:33:31 -0700) References: <87a7uj24kk.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.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: -5.0 (-----) > From: Gemini Lasswell > Date: Tue, 03 Apr 2018 17:33:31 -0700 > > I just got acquainted with inline-letevals and found its description > in the Elisp manual confusing because the purpose of the macro is not > stated, and it is described as similar to 'let' without mention of an > important difference in what happens to the elements of the bindings > list which are symbols. > > Here's a patch to functions.texi where I've attempted to clarify the > description. Thanks, but your text left me confused, perhaps because it mixes the details of the syntax and semantics with the explanation of why and how to use them, and what is the result of such usage. These should be generally kept separate for clarity. How about if you first tell informally what information is missing from the original text, and then we see how to augment that by adding the missing bits? From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals In-Reply-To: <87a7uj24kk.fsf@runbox.com> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 13:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 31052@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15228479393066 (code B ref -1); Wed, 04 Apr 2018 13:19:01 +0000 Received: (at submit) by debbugs.gnu.org; 4 Apr 2018 13:18:59 +0000 Received: from localhost ([127.0.0.1]:37844 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3iJX-0000nO-Do for submit@debbugs.gnu.org; Wed, 04 Apr 2018 09:18:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42275) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3iJV-0000nB-Py for submit@debbugs.gnu.org; Wed, 04 Apr 2018 09:18:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3iJP-0001Ek-GV for submit@debbugs.gnu.org; Wed, 04 Apr 2018 09:18:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41590) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f3iJP-0001Ee-DD for submit@debbugs.gnu.org; Wed, 04 Apr 2018 09:18:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3iJM-00013L-Ap for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 09:18:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3iJG-0001Cd-HS for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 09:18:48 -0400 Received: from [195.159.176.226] (port=42406 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3iJG-0001Bm-AR for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 09:18:42 -0400 Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1f3iH7-0005cc-L3 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 15:16:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ From: Andy Moreton Date: Wed, 04 Apr 2018 14:18:32 +0100 Lines: 51 Message-ID: References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=shift_jis Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (windows-nt) Cancel-Lock: sha1:NFzrJ5iGszr5Zs1p1N4p3XRbzr4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.5 (----) 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: -4.5 (----) On Wed 04 Apr 2018, Eli Zaretskii wrote: >> From: Gemini Lasswell >> Date: Tue, 03 Apr 2018 17:33:31 -0700 >> >> I just got acquainted with inline-letevals and found its description >> in the Elisp manual confusing because the purpose of the macro is not >> stated, and it is described as similar to 'let' without mention of an >> important difference in what happens to the elements of the bindings >> list which are symbols. >> >> Here's a patch to functions.texi where I've attempted to clarify the >> description. > > Thanks, but your text left me confused, perhaps because it mixes the > details of the syntax and semantics with the explanation of why and > how to use them, and what is the result of such usage. These should > be generally kept separate for clarity. > > How about if you first tell informally what information is missing > from the original text, and then we see how to augment that by adding > the missing bits? The same node in the elisp manual has this: Functions defined via edefine-inlinef have several advantages with respect to macros defined by edefsubstf or edefmacrof: and this: | They behave in a more predictable way than ecl-defsubstf (*note (cl)Argument Lists::). It would be more consistent to use defsubst or cl-defsubst in both places. Also, while looking at inline-letevals in inline.el, I noticed that the preceeding macros inline--leteval and inline--letlisteval mention the wrong symbol name in their error messages: (defmacro inline--leteval (_var-exp &rest _body) (declare (indent 1) (debug (sexp &rest body))) (error "inline-letevals can only be used within define-inline")) (defmacro inline--letlisteval (_list &rest _body) (declare (indent 1) (debug (sexp &rest body))) (error "inline-letevals can only be used within define-inline")) Perhaps these typos can be fixed before the release. AndyM From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 14:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andy Moreton , Stefan Monnier Cc: 31052@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.15228508027963 (code B ref 31052); Wed, 04 Apr 2018 14:07:02 +0000 Received: (at 31052) by debbugs.gnu.org; 4 Apr 2018 14:06:42 +0000 Received: from localhost ([127.0.0.1]:38455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3j3i-00024N-Lq for submit@debbugs.gnu.org; Wed, 04 Apr 2018 10:06:42 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3j3h-00024B-80 for 31052@debbugs.gnu.org; Wed, 04 Apr 2018 10:06:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3j3Y-0004k0-4R for 31052@debbugs.gnu.org; Wed, 04 Apr 2018 10:06:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3j3X-0004jr-W6; Wed, 04 Apr 2018 10:06:32 -0400 Received: from [176.228.60.248] (port=4935 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f3j3X-0002Wa-EM; Wed, 04 Apr 2018 10:06:31 -0400 Date: Wed, 04 Apr 2018 17:06:42 +0300 Message-Id: <83y3i32hhp.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Andy Moreton on Wed, 04 Apr 2018 14:18:32 +0100) References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.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: -5.0 (-----) > From: Andy Moreton > Date: Wed, 04 Apr 2018 14:18:32 +0100 > > Also, while looking at inline-letevals in inline.el, I noticed that the > preceeding macros inline--leteval and inline--letlisteval mention the > wrong symbol name in their error messages: > > (defmacro inline--leteval (_var-exp &rest _body) > (declare (indent 1) (debug (sexp &rest body))) > (error "inline-letevals can only be used within define-inline")) > > (defmacro inline--letlisteval (_list &rest _body) > (declare (indent 1) (debug (sexp &rest body))) > (error "inline-letevals can only be used within define-inline")) > > Perhaps these typos can be fixed before the release. It's not too late for that, but I'm not sure this is a typo. It could be deliberate. Stefan, can you comment on this, please? From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 31052@debbugs.gnu.org Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.152286186224305 (code B ref 31052); Wed, 04 Apr 2018 17:12:02 +0000 Received: (at 31052) by debbugs.gnu.org; 4 Apr 2018 17:11:02 +0000 Received: from localhost ([127.0.0.1]:38537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3lw6-0006Jw-BD for submit@debbugs.gnu.org; Wed, 04 Apr 2018 13:11:02 -0400 Received: from aibo.runbox.com ([91.220.196.211]:41184) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3lw3-0006JX-Ut for 31052@debbugs.gnu.org; Wed, 04 Apr 2018 13:11:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to: Subject:Cc:To:From:References; bh=Aoktw11cXoPttzBvGUamq9dslJVfckqLySc43kI/Ba4=; b=Dzgbutn4APCaMfLqWjv3IjBL2N va2RlXLSK1gWgeo3zaqQYDEXG6Dz+WmICAh/5aIXv116JrkOIHj3l5frzpfDEzvCLuySEeVAtGmh/ gab1s1zpkMkjCeZkWHgp6552XPvx9rv2uOL9Dxkmx6j9Iv/1GfrUDAjut1DEixmWOJo+6NDiQq92h Y61aPOiWLyRVfQPYDJYMdV5Nt4XuQZpZafTox7YXt8CSyk4PoJ1UKyOMCi9oIGaxmjxPAQdhXBh04 ACrq0NaWfiAmWu0rLCJ6it1M1eCPmHxzFpCMRpGC0TjX8umx3LZtDEeKq+TSNWizaVyILpYon56Iv dXcjCOOA==; Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1f3lw2-0002ge-FF; Wed, 04 Apr 2018 19:10:58 +0200 Received: from c-24-22-244-161.hsd1.wa.comcast.net ([24.22.244.161] helo=sockeye) by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1f3lvt-0000MD-Q0; Wed, 04 Apr 2018 19:10:50 +0200 References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> User-agent: mu4e 0.9.18; emacs 26.0.91 From: Gemini Lasswell In-reply-to: <83efjv4ggx.fsf@gnu.org> Date: Wed, 04 Apr 2018 10:10:39 -0700 Message-ID: <87vad6zyls.fsf@runbox.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) 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.7 (/) Eli Zaretskii writes: > How about if you first tell informally what information is missing > from the original text, and then we see how to augment that by adding > the missing bits? The main question the existing documentation doesn't answer is what the purpose of inline-letevals is and why it should be used instead of 'let'. The misleading part of the existing documentation is that it describes inline-letevals as similar to 'let' without mentioning that it does a completely different thing to symbols in the binding list. From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Apr 2018 01:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 31052@debbugs.gnu.org, Andy Moreton Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.15228907501256 (code B ref 31052); Thu, 05 Apr 2018 01:13:01 +0000 Received: (at 31052) by debbugs.gnu.org; 5 Apr 2018 01:12:30 +0000 Received: from localhost ([127.0.0.1]:38795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3tS2-0000KC-Fh for submit@debbugs.gnu.org; Wed, 04 Apr 2018 21:12:30 -0400 Received: from pmta11.teksavvy.com ([76.10.157.34]:64828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3tRz-0000Jw-NZ for 31052@debbugs.gnu.org; Wed, 04 Apr 2018 21:12:29 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2E5EQCAd8Va/06mSC1dGwEBAQEDAQEBCQEBAYNCgVCIKZBmgXQTfJRPC4UDAoRBITgUAQIBAQEBAQECAgJoKIUkAQQBeRALDScSFBgxhRgIrmsaAogpgiWHYoITg1w0iiMgAotzi0sIj2ODWYIoIoRnj32BJTMigVIzGggwgn6QaSOOHAEB X-IPAS-Result: A2E5EQCAd8Va/06mSC1dGwEBAQEDAQEBCQEBAYNCgVCIKZBmgXQTfJRPC4UDAoRBITgUAQIBAQEBAQECAgJoKIUkAQQBeRALDScSFBgxhRgIrmsaAogpgiWHYoITg1w0iiMgAotzi0sIj2ODWYIoIoRnj32BJTMigVIzGggwgn6QaSOOHAEB X-IronPort-AV: E=Sophos;i="5.48,409,1517893200"; d="scan'208";a="26760963" Received: from unknown (HELO fmsmemgm.homelinux.net) ([45.72.166.78]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2018 21:12:21 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id AC011AE1ED; Wed, 4 Apr 2018 21:12:21 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> <83y3i32hhp.fsf@gnu.org> Date: Wed, 04 Apr 2018 21:12:21 -0400 In-Reply-To: <83y3i32hhp.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Apr 2018 17:06:42 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.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: 0.3 (/) >> Also, while looking at inline-letevals in inline.el, I noticed that the >> preceeding macros inline--leteval and inline--letlisteval mention the >> wrong symbol name in their error messages: >> >> (defmacro inline--leteval (_var-exp &rest _body) >> (declare (indent 1) (debug (sexp &rest body))) >> (error "inline-letevals can only be used within define-inline")) >> >> (defmacro inline--letlisteval (_list &rest _body) >> (declare (indent 1) (debug (sexp &rest body))) >> (error "inline-letevals can only be used within define-inline")) >> >> Perhaps these typos can be fixed before the release. > > It's not too late for that, but I'm not sure this is a typo. It could > be deliberate. > > Stefan, can you comment on this, please? Good catch: these aren't typos! The inline-letevals macro expands to calls to inline--leteval and inline--letlisteval and it's easier to have those signal the error than to make inline-letevals check whether we're within a define-inline. The user is not supposed to use inline--leteval or inline--letlisteval manually anywhere at all (as indicated by the "--" in their name), so if those occur it's (presumably) because of an incorrect use of inline-letevals. I'll add a comment about it, to stop other people from trying to "fix" it. Stefan From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Apr 2018 09:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gemini Lasswell Cc: 31052@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.152292208916111 (code B ref 31052); Thu, 05 Apr 2018 09:55:02 +0000 Received: (at 31052) by debbugs.gnu.org; 5 Apr 2018 09:54:49 +0000 Received: from localhost ([127.0.0.1]:38918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f41bU-0004Bn-PD for submit@debbugs.gnu.org; Thu, 05 Apr 2018 05:54:48 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f41bT-0004Ba-M1 for 31052@debbugs.gnu.org; Thu, 05 Apr 2018 05:54:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f41bL-0006dj-BE for 31052@debbugs.gnu.org; Thu, 05 Apr 2018 05:54:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f41bL-0006da-82; Thu, 05 Apr 2018 05:54:39 -0400 Received: from [176.228.60.248] (port=2813 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f41bK-00085v-Ll; Thu, 05 Apr 2018 05:54:39 -0400 Date: Thu, 05 Apr 2018 12:54:51 +0300 Message-Id: <834lkq2d1w.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87vad6zyls.fsf@runbox.com> (message from Gemini Lasswell on Wed, 04 Apr 2018 10:10:39 -0700) References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> <87vad6zyls.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.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: -5.0 (-----) > From: Gemini Lasswell > Cc: 31052@debbugs.gnu.org > Date: Wed, 04 Apr 2018 10:10:39 -0700 > > > How about if you first tell informally what information is missing > > from the original text, and then we see how to augment that by adding > > the missing bits? > > The main question the existing documentation doesn't answer is what the > purpose of inline-letevals is and why it should be used instead of 'let'. OK, but in that case we need only add a single sentence: This provides a convenient way to ensure that the arguments to an inlined function are evaluated exactly once, as well as to create local variables. > The misleading part of the existing documentation is that it describes > inline-letevals as similar to 'let' without mentioning that it does a > completely different thing to symbols in the binding list. The only part of your change that I perceive as related to this is the following sentence: When an element of @var{bindings} is just a symbol @var{var}, the result of evaluating @var{var} is re-bound to @var{var}. Is this what caused you to say it "does a completely different thing to symbols in the binding list"? Or did I misunderstand? Thanks. From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Apr 2018 20:30:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 31052@debbugs.gnu.org Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.152304657510139 (code B ref 31052); Fri, 06 Apr 2018 20:30:01 +0000 Received: (at 31052) by debbugs.gnu.org; 6 Apr 2018 20:29:35 +0000 Received: from localhost ([127.0.0.1]:40671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4XzK-0002dT-Q0 for submit@debbugs.gnu.org; Fri, 06 Apr 2018 16:29:34 -0400 Received: from aibo.runbox.com ([91.220.196.211]:57532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f4XzI-0002dK-Iy for 31052@debbugs.gnu.org; Fri, 06 Apr 2018 16:29:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to: Subject:Cc:To:From:References; bh=W5LKm88lP2hWOtoaRc0kYJZEILpai0bwGeU5LULOwxA=; b=lRXHSrRBr9mAkJ6xMXZ18vSWac vTV0qCh85WaEWCRCSojd772PZz5zuAQezFwuOnOEsefWssUitzIp9jMjkrONDzI9Ye+FtQ1lv8GgJ y4Z6/V7Jnrq6gVtThybnQCTfaZBcxOY8WbOwArgK0MZYxZVV/QDev/pL3dZYfIXXcggkHteqDQqfw 0C5LRjkqvRiMAgIivyULBmqD++gkqWf9sZfIklGv8KWzEY07Du3i1KIByIKsP6E47HnqTZ0H9g3sz oGDjRxx2PFW6n+3vZ5M1GBDbUsDDpq5jywQxPp+vClZ9Aq1pmMGgVxVixrYoTHWxHh/Rw0YQJlDT1 oRjT/eMA==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1f4XzH-0003Yg-23; Fri, 06 Apr 2018 22:29:31 +0200 Received: from c-24-22-244-161.hsd1.wa.comcast.net ([24.22.244.161] helo=chinook) by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1f4XzC-00073f-10; Fri, 06 Apr 2018 22:29:26 +0200 References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> <87vad6zyls.fsf@runbox.com> <834lkq2d1w.fsf@gnu.org> User-agent: mu4e 0.9.18; emacs 26.0.91 From: Gemini Lasswell In-reply-to: <834lkq2d1w.fsf@gnu.org> Date: Fri, 06 Apr 2018 13:29:23 -0700 Message-ID: <87o9iw13ks.fsf@runbox.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) 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.7 (-) Eli Zaretskii writes: > When an element of @var{bindings} is just a symbol @var{var}, the > result of evaluating @var{var} is re-bound to @var{var}. > > Is this what caused you to say it "does a completely different thing > to symbols in the binding list"? Or did I misunderstand? > What caused me to say it does a completely different thing is that, for example, if VAR is bound to 3 in an outside scope, inside: (let (var) ...) it will be bound to nil. But inside (inline-letevals (var) ...) it will be bound to 3. And if VAR is unbound in the outside scope, let will bind it to nil and inline-letevals will signal an error. It's occurred to me while writing this that (inline-letevals (var) ...) behaves much like (let ((var (eval var))) ...) although I'm not sure how to turn that into a concise explanation for the documentation. From unknown Fri Jun 13 11:49:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#31052: 26.0.91; Improve documentation of inline-letevals Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Aug 2020 16:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31052 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Gemini Lasswell , 31052@debbugs.gnu.org Received: via spool by 31052-submit@debbugs.gnu.org id=B31052.159811200216718 (code B ref 31052); Sat, 22 Aug 2020 16:01:01 +0000 Received: (at 31052) by debbugs.gnu.org; 22 Aug 2020 16:00:02 +0000 Received: from localhost ([127.0.0.1]:51111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9Vw1-0004L6-5X for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:00:01 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9Vvz-0004Ko-3H for 31052@debbugs.gnu.org; Sat, 22 Aug 2020 11:59:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LOijZqM1KstwFrEB6dbnTJVvEgxrNZ7Xrct6xmbM7WI=; b=WNuOKyPj8tX2GwO6LP9z//nuX5 KQl7O7hM4AnQy3bWGB1zE27473Cwzp3EIrodnwWy/U4eIVYcBjw9fvVwiiQAWkB9OlVMNsRMqyY2w vgJ9wnixH4xb+9q/U0qFkmip5smlQbhieuEISSwoEThW797WpJrXBab9l/oHCXCubbto=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9Vvo-0000mC-QC; Sat, 22 Aug 2020 17:59:52 +0200 From: Lars Ingebrigtsen References: <87a7uj24kk.fsf@runbox.com> <83efjv4ggx.fsf@gnu.org> <87vad6zyls.fsf@runbox.com> <834lkq2d1w.fsf@gnu.org> X-Now-Playing: Nettle's _Firecamp Stories Remixes_: "I-O - Desert Like Tundra" Date: Sat, 22 Aug 2020 17:59:47 +0200 In-Reply-To: <834lkq2d1w.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Apr 2018 12:54:51 +0300") Message-ID: <871rjyk6x8.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> The main question the existing documentation doesn't answer is what the >> purpose of inline-letevals is and why it should be used instead of 'let'. > > OK, but in that case we need only add a sing [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: >> The main question the existing documentation doesn't answer is what the >> purpose of inline-letevals is and why it should be used instead of 'let'. > > OK, but in that case we need only add a single sentence: > > This provides a convenient way to ensure that the arguments to an > inlined function are evaluated exactly once, as well as to create > local variables. > >> The misleading part of the existing documentation is that it describes >> inline-letevals as similar to 'let' without mentioning that it does a >> completely different thing to symbols in the binding list. > > The only part of your change that I perceive as related to this is the > following sentence: > > When an element of @var{bindings} is just a symbol @var{var}, the > result of evaluating @var{var} is re-bound to @var{var}. I agree with Gemini that the description of inline-letevals was confusing, and I also agree with Eli that the proposed patch was also confusing. :-) So I've taken Eli's suggestion, and the sentence above and added them to the manual, as well as adding a bit more text to explain what it's doing, and where it differs from `let', and pushed to Emacs 28. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 12:00:07 2020 Received: (at control) by debbugs.gnu.org; 22 Aug 2020 16:00:07 +0000 Received: from localhost ([127.0.0.1]:51114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9Vw6-0004PZ-Rc for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:00:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9Vw5-0004L2-1U for control@debbugs.gnu.org; Sat, 22 Aug 2020 12:00:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wgWO5I7kC5j0NigJM35UKyRZfA1rncMiBf5HOrLFs+U=; b=Nx6alC/K/s+S3uKaQO/W1duXz7 3HRBeuQUGAZsJLpofBCrzWAEbQkLV0ZHZmpv5tBTm7SFoybxJDn+bVK3jMTsKzkUnWBCScmvTV88/ 9TDJraGLJypt+0BNv4Z4gQpskhwYe9gXDlB45fRD7SPWVuV06x/pkPE5clcpfLlDNy4o=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9Vvx-0000mL-6r for control@debbugs.gnu.org; Sat, 22 Aug 2020 17:59:59 +0200 Date: Sat, 22 Aug 2020 17:59:56 +0200 Message-Id: <87zh6miscj.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #31052 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 31052 fixed close 31052 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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 (-) tags 31052 fixed close 31052 28.1 quit