From unknown Sun Jun 22 00:02:55 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#21199 <21199@debbugs.gnu.org> To: bug#21199 <21199@debbugs.gnu.org> Subject: Status: yank-pop problem Reply-To: bug#21199 <21199@debbugs.gnu.org> Date: Sun, 22 Jun 2025 07:02:55 +0000 retitle 21199 yank-pop problem reassign 21199 emacs submitter 21199 frederik@ofb.net severity 21199 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 06 11:33:30 2015 Received: (at submit) by debbugs.gnu.org; 6 Aug 2015 15:33:30 +0000 Received: from localhost ([127.0.0.1]:41358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZNNAf-0001uP-7Y for submit@debbugs.gnu.org; Thu, 06 Aug 2015 11:33:30 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35369) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZNFlC-0005dN-AM for submit@debbugs.gnu.org; Thu, 06 Aug 2015 03:38:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNFlA-0006I4-I9 for submit@debbugs.gnu.org; Thu, 06 Aug 2015 03:38:41 -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 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNFlA-0006Ha-FU for submit@debbugs.gnu.org; Thu, 06 Aug 2015 03:38:40 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNFl8-0005wG-FY for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2015 03:38:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNFl4-0006Ez-6X for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2015 03:38:38 -0400 Received: from ofb.net ([64.13.131.34]:54668) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNFl3-0006DR-MD; Thu, 06 Aug 2015 03:38:33 -0400 Received: by ofb.net (Postfix, from userid 30017) id B2A1D20706E5; Thu, 6 Aug 2015 00:38:31 -0700 (PDT) Date: Thu, 6 Aug 2015 00:38:31 -0700 From: Frederik Eaton To: help-gnu-emacs@gnu.org Subject: yank-pop problem Message-ID: <20150806073831.GA4560@ofb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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: -5.0 (-----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 06 Aug 2015 11:33:28 -0400 Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: frederik@ofb.net 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 (-----) Dear Help-Gnu-Emacs, I was chatting on the #emacs freenode.net IRC channel and thought to ask people about a long-standing annoyance I've had with Emacs. One IRC user was horrified that I would find anything wrong with Emacs, but another user suggested that I write up a document with the details and send it as a bug report. So I wrote up a document which explains the issue and how I think it should be fixed. I'm pasting it below and would appreciate your comments. Mostly I'm looking to see if anyone else has previously implemented this suggestion, and is willing to share their code. I hope my thoughts are explained clearly enough. Thanks! Frederick P.S. I Cc'ed bug-gnu-emacs@gnu.org because I figured problems go there, but I haven't subscribed to that list and I'm not really expecting the core of Emacs to be changed. P.P.S. After writing this (typically of me) I just noticed that somebody else posted this problem on stackoverflow.com in 2011! However, none of the solutions posted there are really suitable in my opinion. The basic problem, which is that Emacs puts stuff you don't care about in the kill ring ahead of stuff that you do care about, isn't ever fixed. Although the first ("jp/yank") solution is nearly good enough, it still allows text we care about to get clobbered if there is an intervening yank... http://stackoverflow.com/questions/5823495/emacs-how-to-yank-the-last-yanked-text-regardless-of-subsequent-kills ---------------------------------------------------------------- Emacs Yank Pointer Problem Description Problem: In Emacs, I can use C-y (yank) and then M-y (yank-pop) to go through a list of recent bits of text which have been killed. Having done this, the next time I do C-y, it yanks the last bit of text selected via M-y. This is desired since it means I don't have to rotate through the list to find my favorite item again. This behavior is implemented using the variable "kill-ring-yank-pointer" which points to the last "yank-pop"ed item in the kill ring. However, when I kill some text, the value of "kill-ring-yank-pointer" is reset to point to the head of the "kill ring". This resetting means that when I am interspersing a number of yanks (of the same item of text) with an editing command such as M-d which also populates the kill ring, then my "kill-ring-yank-pointer" is reset each time, and each time I yank, I have to search farther and farther back with an increasing number of M-y keystrokes, just to get the same item I've been yanking. In short, when (say) I am replacing a few strings manually with some text from the kill ring, I end up doing C-y, then for the next replacement C-y M-y, then next C-y M-y M-y, and next C-y M-y M-y M-y, and so on. I'll give a concrete tutorial. Try replacing every animal in the following list with "dog", using only "M-d" and "C-y" and "M-y", and "C-a" and "C-n". dog cat ant chicken The kill ring will first look like ("dog"), then ("cat" "dog"), then ("ant" "cat" "dog"), then ("chicken" "ant" "cat" "dog"). After the final yank-pop of each line, the kill-ring-yank-pointer will point to "dog" at the end of the kill ring. However, when you use M-d to delete the animal being replaced, then kill-ring-yank-pointer gets reset, and so it is never used. Proposed solution: The kill ring, which is a list, should be treated as an array by yank-pop, and rearranged more freely. Killing text should still put stuff at the front of the list, as before. However, each yank-pop'ed item will also be moved to the front of the kill ring. Yank-pop should use a new variable to serve the purpose of "kill-ring-yank-pointer". Rather than pointing to an existing item in the kill ring, the new variable will be an index into the kill ring, which just tells yank-pop how to fix up the kill ring in case the last command was yank-pop. For example, suppose the kill ring looks like this: (I) A B C D E C-y M-y M-y will end up with C being inserted at the cursor. After that, we DON'T want the kill ring to look like "C D E A B" because we care more about A and B than about D or E, as they are more recently used items. What we do want it to look like is (II) C A B D E But suppose the next command is also M-y. Then the kill ring should look like (III) D A B C E because we care more about A and B than about C (since C we saw only on our way to D, and didn't end up using it). In order to obtain this configuration, yank-pop will have to have inserted C back where it came from, and moved D to the front. It would presumably do this with an integer variable which is incremented at each yank-pop, and reset to 0 in the 'yank' command, to guide the insertion and extraction of elements from the kill ring. To be specific, let's call the new variable "kill-ring-yank-pop-index". In state (I) above, "kill-ring-yank-pop-index" could have an arbitrary value, but it is reset to zero by "yank". In state (II) above, it would have the value 2 to indicate that C came from position 2 in the (zero-indexed) kill ring. In state (III), it would have value 3 - at that point, yank-pop will have read the value 2 from "kill-ring-yank-pop-index", used that to put C back into the list at position 2, moved D to the front, and incremented the value to 3. The END. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 06 19:49:55 2015 Received: (at submit) by debbugs.gnu.org; 6 Aug 2015 23:49:55 +0000 Received: from localhost ([127.0.0.1]:41609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZNUv4-0004hO-Oi for submit@debbugs.gnu.org; Thu, 06 Aug 2015 19:49:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40613) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZNUv2-0004hG-4S for submit@debbugs.gnu.org; Thu, 06 Aug 2015 19:49:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNUv0-00021P-5Y for submit@debbugs.gnu.org; Thu, 06 Aug 2015 19:49:51 -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 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:49606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNUv0-00021J-2n for submit@debbugs.gnu.org; Thu, 06 Aug 2015 19:49:50 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNUuy-0002bJ-Dz for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2015 19:49:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNUuv-0001xa-1e for bug-gnu-emacs@gnu.org; Thu, 06 Aug 2015 19:49:48 -0400 Received: from ofb.net ([64.13.131.34]:43701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNUuu-0001xS-Q1; Thu, 06 Aug 2015 19:49:44 -0400 Received: by ofb.net (Postfix, from userid 30017) id 3BECD20706E0; Thu, 6 Aug 2015 16:49:43 -0700 (PDT) Date: Thu, 6 Aug 2015 16:49:43 -0700 From: Frederik Eaton To: help-gnu-emacs@gnu.org Subject: Re: yank-pop problem Message-ID: <20150806234942.GA6355@ofb.net> References: <20150806073831.GA4560@ofb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150806073831.GA4560@ofb.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: frederik@ofb.net 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 (-----) I just coded up a solution and posted it under "A Better Yank-Pop Implementation" in the stackoverflow thread: http://stackoverflow.com/questions/5823495/emacs-how-to-yank-the-last-yanked-text-regardless-of-subsequent-kills On Thu, Aug 06, 2015 at 12:38:31AM -0700, Frederik Eaton wrote: > Dear Help-Gnu-Emacs, > > I was chatting on the #emacs freenode.net IRC channel and thought to > ask people about a long-standing annoyance I've had with Emacs. One > IRC user was horrified that I would find anything wrong with Emacs, > but another user suggested that I write up a document with the details > and send it as a bug report. So I wrote up a document which explains > the issue and how I think it should be fixed. I'm pasting it below and > would appreciate your comments. Mostly I'm looking to see if anyone > else has previously implemented this suggestion, and is willing to > share their code. I hope my thoughts are explained clearly enough. > > Thanks! > > Frederick > > P.S. I Cc'ed bug-gnu-emacs@gnu.org because I figured problems go > there, but I haven't subscribed to that list and I'm not really > expecting the core of Emacs to be changed. > > P.P.S. After writing this (typically of me) I just noticed that > somebody else posted this problem on stackoverflow.com in 2011! > However, none of the solutions posted there are really suitable in my > opinion. The basic problem, which is that Emacs puts stuff you don't > care about in the kill ring ahead of stuff that you do care about, > isn't ever fixed. Although the first ("jp/yank") solution is nearly > good enough, it still allows text we care about to get clobbered if > there is an intervening yank... > > http://stackoverflow.com/questions/5823495/emacs-how-to-yank-the-last-yanked-text-regardless-of-subsequent-kills > > > > ---------------------------------------------------------------- > > Emacs Yank Pointer Problem Description > > Problem: > > In Emacs, I can use C-y (yank) and then M-y (yank-pop) to go through a > list of recent bits of text which have been killed. > > Having done this, the next time I do C-y, it yanks the last bit of > text selected via M-y. This is desired since it means I don't have to > rotate through the list to find my favorite item again. This behavior > is implemented using the variable "kill-ring-yank-pointer" which > points to the last "yank-pop"ed item in the kill ring. > > However, when I kill some text, the value of "kill-ring-yank-pointer" > is reset to point to the head of the "kill ring". This resetting means > that when I am interspersing a number of yanks (of the same item of > text) with an editing command such as M-d which also populates the > kill ring, then my "kill-ring-yank-pointer" is reset each time, and > each time I yank, I have to search farther and farther back with an > increasing number of M-y keystrokes, just to get the same item I've > been yanking. > > In short, when (say) I am replacing a few strings manually with some > text from the kill ring, I end up doing C-y, then for the next > replacement C-y M-y, then next C-y M-y M-y, and next C-y M-y M-y M-y, > and so on. > > I'll give a concrete tutorial. Try replacing every animal in the > following list with "dog", using only "M-d" and "C-y" and "M-y", and > "C-a" and "C-n". > > dog > cat > ant > chicken > > The kill ring will first look like ("dog"), then ("cat" "dog"), then > ("ant" "cat" "dog"), then ("chicken" "ant" "cat" "dog"). After the > final yank-pop of each line, the kill-ring-yank-pointer will point to > "dog" at the end of the kill ring. However, when you use M-d to delete > the animal being replaced, then kill-ring-yank-pointer gets reset, and > so it is never used. > > > Proposed solution: > > The kill ring, which is a list, should be treated as an array by > yank-pop, and rearranged more freely. > > Killing text should still put stuff at the front of the list, as > before. > > However, each yank-pop'ed item will also be moved to the front of the > kill ring. > > Yank-pop should use a new variable to serve the purpose of > "kill-ring-yank-pointer". Rather than pointing to an existing item in > the kill ring, the new variable will be an index into the kill ring, > which just tells yank-pop how to fix up the kill ring in case the last > command was yank-pop. For example, suppose the kill ring looks like > this: > > (I) A B C D E > > C-y M-y M-y will end up with C being inserted at the cursor. After > that, we DON'T want the kill ring to look like "C D E A B" because we > care more about A and B than about D or E, as they are more recently > used items. What we do want it to look like is > > (II) C A B D E > > But suppose the next command is also M-y. Then the kill ring should > look like > > (III) D A B C E > > because we care more about A and B than about C (since C we saw only > on our way to D, and didn't end up using it). In order to obtain this > configuration, yank-pop will have to have inserted C back where it > came from, and moved D to the front. It would presumably do this with > an integer variable which is incremented at each yank-pop, and reset > to 0 in the 'yank' command, to guide the insertion and extraction of > elements from the kill ring. > > To be specific, let's call the new variable > "kill-ring-yank-pop-index". In state (I) above, > "kill-ring-yank-pop-index" could have an arbitrary value, but it is > reset to zero by "yank". In state (II) above, it would have the value > 2 to indicate that C came from position 2 in the (zero-indexed) kill > ring. In state (III), it would have value 3 - at that point, yank-pop > will have read the value 2 from "kill-ring-yank-pop-index", used that > to put C back into the list at position 2, moved D to the front, and > incremented the value to 3. > > The END. > From debbugs-submit-bounces@debbugs.gnu.org Wed May 26 18:54:06 2021 Received: (at 21199) by debbugs.gnu.org; 26 May 2021 22:54:06 +0000 Received: from localhost ([127.0.0.1]:50222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lm2Pe-0004YK-AS for submit@debbugs.gnu.org; Wed, 26 May 2021 18:54:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lm2Pc-0004Xp-K0 for 21199@debbugs.gnu.org; Wed, 26 May 2021 18:54:05 -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=4iSVT/Xmm6MPYG/pkYUJpEYWeF+i+TtELEOr8omtZRs=; b=aI/tMePL5k63QTj5z1dvUjWVNH e3X8fkyD8/1sqwqTltQfZqvRexjoWub0TGWFQdVDMoa+P+98A+XyO+5h4zu1f67j1dQG8OWD/yT/V d96RPcpWcGa4LombgfqX0Vir+tU63I6WnnSUAqjmWFzu729D0Kvo20YVBC/DDYLIN86E=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lm2PT-0004EG-Kt; Thu, 27 May 2021 00:53:57 +0200 From: Lars Ingebrigtsen To: Frederik Eaton Subject: Re: bug#21199: yank-pop problem References: <20150806073831.GA4560@ofb.net> X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Cell Life" Date: Thu, 27 May 2021 00:53:55 +0200 In-Reply-To: <20150806073831.GA4560@ofb.net> (Frederik Eaton's message of "Thu, 6 Aug 2015 00:38:31 -0700") Message-ID: <87bl8x85to.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: Frederik Eaton writes: > Killing text should still put stuff at the front of the list, as > before. > > However, each yank-pop'ed item will also be moved to the front of the > kill ring. 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: 21199 Cc: 21199@debbugs.gnu.org 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 (-) Frederik Eaton writes: > Killing text should still put stuff at the front of the list, as > before. > > However, each yank-pop'ed item will also be moved to the front of the > kill ring. (I'm going through old bug reports that unfortunately got no response at the time.) People have wildly differing usage patterns for killing/yanking, and there's a bunch of different packages for customising how yanking is to be performed. But I don't think it would be appropriate to change how the built-in yanking is done here -- it would annoy too many people, no matter how you do it. (In the concrete example you're describing, I think many people just use registers instead, because the kill ring is too ephemeral.) So I'm closing this bug report -- this is best left to different packages to implement. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed May 26 18:54:12 2021 Received: (at control) by debbugs.gnu.org; 26 May 2021 22:54:12 +0000 Received: from localhost ([127.0.0.1]:50225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lm2Pk-0004Yk-JA for submit@debbugs.gnu.org; Wed, 26 May 2021 18:54:12 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lm2Pj-0004YL-GR for control@debbugs.gnu.org; Wed, 26 May 2021 18:54:11 -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=TuHrH/d6ypZAxMPt32WfHTyaUpWy8bVvVRLXSiMvNqc=; b=iLOj40FowtGHWZ/p/hQlMhTlFe 5eYTBiGTEzpQxVyJoYO5eXP99LRobjnQCU5FIdX5M8DKZnPJcFX35HWOtp9/X0AuTZVT++a9ezrcN KVJxvB6unMDOFJgFuP4+SaddvT6oLgMM/EsRIeLJn2xJQAs8escPyez39b6GRXggmKA8=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lm2Pb-0004ER-W8 for control@debbugs.gnu.org; Thu, 27 May 2021 00:54:05 +0200 Date: Thu, 27 May 2021 00:54:03 +0200 Message-Id: <87a6oh85tg.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #21199 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 21199 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 (-) close 21199 quit From unknown Sun Jun 22 00:02:55 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 24 Jun 2021 11:24:10 +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