From unknown Sun Jun 22 11:34:40 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#15042 <15042@debbugs.gnu.org> To: bug#15042 <15042@debbugs.gnu.org> Subject: Status: 24.3.50; while-no-input and input-pending-p Reply-To: bug#15042 <15042@debbugs.gnu.org> Date: Sun, 22 Jun 2025 18:34:40 +0000 retitle 15042 24.3.50; while-no-input and input-pending-p reassign 15042 emacs submitter 15042 michael_heerdegen@web.de severity 15042 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 07 11:40:36 2013 Received: (at submit) by debbugs.gnu.org; 7 Aug 2013 15:40:36 +0000 Received: from localhost ([127.0.0.1]:45693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V75qh-0003a9-Pf for submit@debbugs.gnu.org; Wed, 07 Aug 2013 11:40:35 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59631) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V75qU-0003UL-DO for submit@debbugs.gnu.org; Wed, 07 Aug 2013 11:40:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V75qG-00050k-Pq for submit@debbugs.gnu.org; Wed, 07 Aug 2013 11:40:12 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-100.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM, USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43008) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V75qG-00050F-M3 for submit@debbugs.gnu.org; Wed, 07 Aug 2013 11:40:04 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33029) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V75q9-00067Q-G1 for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 11:40:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V75q2-0004la-JS for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 11:39:57 -0400 Received: from mout.web.de ([212.227.15.3]:57237) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V75q2-0004lN-AK for bug-gnu-emacs@gnu.org; Wed, 07 Aug 2013 11:39:50 -0400 Received: from drachen.dragon ([90.187.127.150]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0LjJPH-1VjRrX16dD-00dXrp for ; Wed, 07 Aug 2013 17:39:48 +0200 From: Michael Heerdegen To: bug-gnu-emacs@gnu.org Subject: 24.3.50; while-no-input and input-pending-p Date: Wed, 07 Aug 2013 17:39:42 +0200 Message-ID: <87wqnx7bnl.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:D9SJgOtv3HMOUu5mpBw52aL0rapt2Gd3BaFUxgiEFLdvLpmNkSn XhDc0ltNUWHBh1n2aOPub+9R3FfLI38k7TuSgSLdQEg8ObADboLEwm3Uc0ogCO9SgGOXk1D M6qo9Yr0S0sHfcq9r3vy71PS2/MTiAfuFFn0UqdxIWU5fxahIVqRHh9ho61NoTR527nW6dE OXaaHUyNCa+KsZ/LKbMsw== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit Cc: Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: michael_heerdegen@web.de 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.4 (---) Hello, I want to discuss if the current implementation of `while-no-input': --8<---------------cut here---------------start------------->8--- (defmacro while-no-input (&rest body) "Execute BODY only as long as there's no pending input. If input arrives, that ends the execution of BODY, and `while-no-input' returns t. Quitting makes it return nil. If BODY finishes, `while-no-input' returns whatever value BODY produced." (declare (debug t) (indent 0)) (let ((catch-sym (make-symbol "input"))) `(with-local-quit (catch ',catch-sym (let ((throw-on-input ',catch-sym)) (or (input-pending-p) (progn ,@body))))))) --8<---------------cut here---------------end--------------->8--- that uses a preliminary `input-pending-p' test is useful. My reasons: 1. `input-pending-p' can (and does) return t in cases were no input is pending (see the doc). In such cases, `while-no-input' just returns t, although no input was given. This contradicts the doc, is not useful and the behavior is unforeseeable. 2. Even if `input-pending-p' would not give false alarm sometimes - why needs `while-no-input' to use it? If the programmer really wants to check for input _before_ starting the calculation, he can do so explicitly. With the current implementation, I have to `discard-input' if I don't want this. 2 is probably arguable, but 1 is really bad. I experienced that (while-no-input code ...) is sometimes semantically equivalent to t without any input. Regards, Michael. In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2) of 2013-08-04 on dex, modified by Debian (emacs-snapshot package, version 2:20130804-1) Windowing system distributor `The X.Org Foundation', version 11.0.11204000 System Description: Debian GNU/Linux testing (jessie) Configured using: `configure --build x86_64-linux-gnu --host x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.3.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3.50/site-lisp:/usr/share/emacs/site-lisp --without-compress-info --with-crt-dir=/usr/lib/x86_64-linux-gnu/ --with-x=yes --with-x-toolkit=gtk3 --with-imagemagick=yes CFLAGS='-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' CPPFLAGS='-D_FORTIFY_SOURCE=2' LDFLAGS='-g -Wl,--as-needed -znocombreloc'' Important settings: value of $LC_ALL: de_DE.utf8 value of $LANG: de_DE.utf8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 07 14:02:17 2013 Received: (at 15042) by debbugs.gnu.org; 7 Aug 2013 18:02:17 +0000 Received: from localhost ([127.0.0.1]:46004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V783s-0004lS-JQ for submit@debbugs.gnu.org; Wed, 07 Aug 2013 14:02:16 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:58394) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V783q-0004lC-PP for 15042@debbugs.gnu.org; Wed, 07 Aug 2013 14:02:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFLd/Nq/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IPAS-Result: Av8EABK/CFFLd/Nq/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="20869490" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Aug 2013 14:02:01 -0400 Received: by pastel.home (Postfix, from userid 20848) id 4446A66AF2; Wed, 7 Aug 2013 14:02:08 -0400 (EDT) From: Stefan Monnier To: Michael Heerdegen Subject: Re: bug#15042: 24.3.50; while-no-input and input-pending-p Message-ID: References: <87wqnx7bnl.fsf@web.de> Date: Wed, 07 Aug 2013 14:02:08 -0400 In-Reply-To: <87wqnx7bnl.fsf@web.de> (Michael Heerdegen's message of "Wed, 07 Aug 2013 17:39:42 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 15042 Cc: 15042@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) > 1. `input-pending-p' can (and does) return t in cases were no input is > pending (see the doc). In such cases, `while-no-input' just returns t, > although no input was given. This contradicts the doc, is not useful > and the behavior is unforeseeable. Those cases where it immediately returns t should hopefully be very similar to those cases where it stops in the middle even tho the event that interrupted it is "ignorable". > 2. Even if `input-pending-p' would not give false alarm sometimes - why > needs `while-no-input' to use it? while-no-input is for code which should runs "transparently" without preventing the user from running his commands. So if the user has already typed the next key before we even get to while-no-input, we definitely should not enter the while-no-input, since while-no-input is implemented such that it is only interrupted by *new* input. > With the current implementation, I have to `discard-input' if I don't > want this. Can you give an example where you'd want to do that? I experienced that (while-no-input code ...) is sometimes semantically equivalent to t without any input. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 07 16:48:31 2013 Received: (at 15042) by debbugs.gnu.org; 7 Aug 2013 20:48:32 +0000 Received: from localhost ([127.0.0.1]:46147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Ael-00034l-2j for submit@debbugs.gnu.org; Wed, 07 Aug 2013 16:48:31 -0400 Received: from mout.web.de ([212.227.15.4]:52141) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7Aei-00034T-9T for 15042@debbugs.gnu.org; Wed, 07 Aug 2013 16:48:29 -0400 Received: from drachen.dragon ([90.186.238.127]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MNcV4-1VDD3v03nm-007HUj for <15042@debbugs.gnu.org>; Wed, 07 Aug 2013 22:48:21 +0200 From: Michael Heerdegen To: Stefan Monnier Subject: Re: bug#15042: 24.3.50; while-no-input and input-pending-p References: <87wqnx7bnl.fsf@web.de> Date: Wed, 07 Aug 2013 22:48:15 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 07 Aug 2013 14:02:08 -0400") Message-ID: <87fvul9qi8.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:sKDHa5xYTCzDyULci+fVnpXZPMlOyFofPfD8qICMvZtiHJrUj1q L95sCr99qTo9vEnLiZ0aQtrUyOo9SA1JOF/K48Mdq4QNYPvyizjp4GFH4eASm02O41Z/gRU dT8atJBFg+Se4VIqx+VTxlD6AJQFtDfSlJCPMOpGVlsz4sYLrt7Ni5J2qs0R0H7DJBNRimH mmwgc2UsfKWEQRBZnyczA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 15042 Cc: 15042@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) Stefan Monnier writes: > > 1. `input-pending-p' can (and does) return t in cases were no input is > > pending (see the doc). In such cases, `while-no-input' just returns t, > > although no input was given. This contradicts the doc, is not useful > > and the behavior is unforeseeable. > > Those cases where it immediately returns t should hopefully be very > similar to those cases where it stops in the middle even tho the event > that interrupted it is "ignorable". Sure? (What are such "ignorable" events?) That would mean that binding `throw-on-input' also "fires" in cases where no input arrived. Is there an alternative to cancel a calculation on input without "false positives"? > > With the current implementation, I have to `discard-input' if I don't > > want this. > > Can you give an example where you'd want to do that? Actually, no. This was hypothetical, maybe unfounded. Regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 07 21:20:06 2013 Received: (at 15042) by debbugs.gnu.org; 8 Aug 2013 01:20:07 +0000 Received: from localhost ([127.0.0.1]:46488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7EtZ-0004gO-NC for submit@debbugs.gnu.org; Wed, 07 Aug 2013 21:20:06 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:42090) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1V7EtV-0004ff-KY for 15042@debbugs.gnu.org; Wed, 07 Aug 2013 21:20:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFLd/Nq/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IPAS-Result: Av8EABK/CFFLd/Nq/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA6R6gV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="20939604" Received: from 75-119-243-106.dsl.teksavvy.com (HELO pastel.home) ([75.119.243.106]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Aug 2013 21:19:48 -0400 Received: by pastel.home (Postfix, from userid 20848) id 360C262EBF; Wed, 7 Aug 2013 21:19:55 -0400 (EDT) From: Stefan Monnier To: Michael Heerdegen Subject: Re: bug#15042: 24.3.50; while-no-input and input-pending-p Message-ID: References: <87wqnx7bnl.fsf@web.de> <87fvul9qi8.fsf@web.de> Date: Wed, 07 Aug 2013 21:19:55 -0400 In-Reply-To: <87fvul9qi8.fsf@web.de> (Michael Heerdegen's message of "Wed, 07 Aug 2013 22:48:15 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 15042 Cc: 15042@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 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 (/) >> > 1. `input-pending-p' can (and does) return t in cases were no input is >> > pending (see the doc). In such cases, `while-no-input' just returns t, >> > although no input was given. This contradicts the doc, is not useful >> > and the behavior is unforeseeable. >> Those cases where it immediately returns t should hopefully be very >> similar to those cases where it stops in the middle even tho the event >> that interrupted it is "ignorable". > Sure? (What are such "ignorable" events?) That would mean that binding > `throw-on-input' also "fires" in cases where no input arrived. Same as for input-pending-p, I think, yes. The issue is not really "no input" but that what you consider as input is not necessarily the same as what Emacs considers as input. E.g. Moving the mouse might send mouse-movement events. Would you consider that as "input"? Emacs sometimes does (e.g. when you select text with the mouse), but in most cases it should be ignored. Emacs tries to get it right, but... > Is there an alternative to cancel a calculation on input without "false > positives"? I don't think so. But we can refine the definition of "input" to ebtter match the user's expectation. >> > With the current implementation, I have to `discard-input' if I don't >> > want this. >> Can you give an example where you'd want to do that? > Actually, no. This was hypothetical, maybe unfounded. If/when you do, please report it, so we can try and fix it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 21 09:50:53 2021 Received: (at 15042) by debbugs.gnu.org; 21 Aug 2021 13:50:53 +0000 Received: from localhost ([127.0.0.1]:36118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHROf-0008Vk-80 for submit@debbugs.gnu.org; Sat, 21 Aug 2021 09:50:53 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHROe-0008VX-AT for 15042@debbugs.gnu.org; Sat, 21 Aug 2021 09:50:52 -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=ivqa7HBSR8ZwAPePTkYvBj/l6N6T6Kik+uUm0UBmVEA=; b=g7OBezGNZCtU3cyNKAli+Y5b1z 8+iXBwZtVh7MwgA/hnWfXfGV6Dor8QIM3NZwzw2Z1SnciwvqMjlh2DwrIVxucndQX/13Iq2VtL1mI FIah9WD6BCoAjp68iHboloK6eKuG6lxweSzsw7y1E/NexH9tOFgDKmcQyTY2EF7aW2FY=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mHROS-0001nV-VE; Sat, 21 Aug 2021 15:50:45 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#15042: 24.3.50; while-no-input and input-pending-p References: <87wqnx7bnl.fsf@web.de> <87fvul9qi8.fsf@web.de> Date: Sat, 21 Aug 2021 15:50:40 +0200 In-Reply-To: <87fvul9qi8.fsf@web.de> (Michael Heerdegen's message of "Wed, 07 Aug 2013 22:48:15 +0200") Message-ID: <874kbi3o0f.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: Michael Heerdegen writes: >> > With the current implementation, I have to `discard-input' if I don't >> > want this. >> >> Can you give an example where you'd want to do that? > > Actually, no. This was hypothetical, maybe unf [...] 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: -2.3 (--) X-Debbugs-Envelope-To: 15042 Cc: 15042@debbugs.gnu.org, Stefan Monnier , Thierry Volpiatto 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 (---) Michael Heerdegen writes: >> > With the current implementation, I have to `discard-input' if I don't >> > want this. >> >> Can you give an example where you'd want to do that? > > Actually, no. This was hypothetical, maybe unfounded. The definition of while-no-input has changed a lot since this issue was opened, but it looks like it's basically functionally equivalent still. Like Stefan, I think the definition looks correct -- we don't want to do BODY even if the keystrokes arrive before `while-no-input' has arrived, and (as you point out) if you don't want that, you can put a `discard-input' before the loop. So I think this is working as designed, and I'm closing this bug report. If there's something to be worked on here, please respond to the debbugs address and we'll reopen. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 21 09:51:02 2021 Received: (at control) by debbugs.gnu.org; 21 Aug 2021 13:51:02 +0000 Received: from localhost ([127.0.0.1]:36122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHROo-0008WT-Gk for submit@debbugs.gnu.org; Sat, 21 Aug 2021 09:51:02 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHROn-0008Vt-K5 for control@debbugs.gnu.org; Sat, 21 Aug 2021 09:51:02 -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=CwN+d0JxbBR2mZl6WAkJJev2GMgfpz7RCjrBN5c0wuk=; b=rECmzgn1jM22us/CC80bpVSjQ8 ycLsXUQkpaOxXAWj42/kb3Yhxmy18moa+I4x138LSHV3C8J4NLYgq1nIAjjlY6ecgq10UXyMdjOrU H3ljzjaYejzZOltkMx+/DJZJnvc/pOyVoBljWu/3wTuiniscepG22ytKLREx0HqPrFiQ=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mHROf-0001ns-Ps for control@debbugs.gnu.org; Sat, 21 Aug 2021 15:50:55 +0200 Date: Sat, 21 Aug 2021 15:50:53 +0200 Message-Id: <8735r23o02.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #15042 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: close 15042 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: -2.3 (--) 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: -3.3 (---) close 15042 quit From unknown Sun Jun 22 11:34:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 19 Sep 2021 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator