From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 06 17:01:31 2020 Received: (at submit) by debbugs.gnu.org; 6 Dec 2020 22:01:31 +0000 Received: from localhost ([127.0.0.1]:51558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km25z-0006KW-3N for submit@debbugs.gnu.org; Sun, 06 Dec 2020 17:01:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:53962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1km25x-0006KP-PK for submit@debbugs.gnu.org; Sun, 06 Dec 2020 17:01:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1km25x-0000HQ-Hp for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 17:01:29 -0500 Received: from dog.birch.relay.mailchannels.net ([23.83.209.48]:50329) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1km25v-0002Dv-TZ for bug-gnu-emacs@gnu.org; Sun, 06 Dec 2020 17:01:29 -0500 X-Sender-Id: dreamhost|x-authsender|jidanni@jidanni.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5CDAD1015EF for ; Sun, 6 Dec 2020 22:01:26 +0000 (UTC) Received: from pdx1-sub0-mail-a24.g.dreamhost.com (100-96-22-168.trex.outbound.svc.cluster.local [100.96.22.168]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 09C9F101779 for ; Sun, 6 Dec 2020 22:01:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jidanni@jidanni.org Received: from pdx1-sub0-mail-a24.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Sun, 06 Dec 2020 22:01:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jidanni@jidanni.org X-MailChannels-Auth-Id: dreamhost X-Spill-Eight: 1a851c0d1ea7bdf5_1607292086252_3964177585 X-MC-Loop-Signature: 1607292086252:2871360531 X-MC-Ingress-Time: 1607292086252 Received: from pdx1-sub0-mail-a24.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTP id B89447EFB1 for ; Sun, 6 Dec 2020 14:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jidanni.org; h=from:to :subject:date:message-id:mime-version:content-type; s= jidanni.org; bh=WmnVngDfGRfAim0jqbPwCz8RcIo=; b=WmOq5gVoQHsae+J1 jPWZXELqQP6oDYJ9BUsc5lVZN0cO8He12iu2DdY7IceQo5DQWW7D8yguf2hLWrWk UYEUHH1baJu0VAcySw0USe1NsAUbsV0Vy78UyWKSklAkXX9G4EaMU29fMwGe7eJJ 7uuaYqRoC96pgPQ8XAb9XCyRBZM= Received: from jidanni.org (114-26-45-21.dynamic-ip.hinet.net [114.26.45.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jidanni@jidanni.org) by pdx1-sub0-mail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 3DB4C8A3D7 for ; Sun, 6 Dec 2020 14:01:24 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a24 From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson To: bug-gnu-emacs@gnu.org Subject: Have so-long mode fire-sprinkler system always ready for M-x compile, M-x shell Date: Sun, 06 Dec 2020 21:12:01 +0800 Message-ID: <87im9fuli6.5.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=23.83.209.48; envelope-from=jidanni@jidanni.org; helo=dog.birch.relay.mailchannels.net X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: submit 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.3 (-) so-long mode is great, when opening files. But what about the case (compile "perl -wle 'print 8 x 888888888;'")? That's going to produce a buffer with a really long line. So so-long mode should jump in to the rescue. And what about M-x shell? If we do $ perl -wle 'print 8 x 888888888;' there, so-long mode should somehow 'detect there is something wrong on the fourth floor of building H, and send in security guards to the rescue' too. $ grep so-long .emacs (global-so-long-mode 1) is what I am using here in emacs-version "27.1" >>>> Norbert N. Nerblesome says: > Just do M-x so-long in the buffer you are uncomfortable with, and you > will see > "Changed to so-long-mode (from compilation-mode). C-c C-c to revert." > So what's the big deal? The big deal is, we, sadly might never have the opportunity to type those "last words and testament," as emacs might already have gotten locked up. Therefore one hopes the problem could be detected for us and so-long mode activated automatically: "Buffer has sprouted long lines. so-long mode activated to prevent emacs jamming itself." From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 06:02:29 2020 Received: (at 45085) by debbugs.gnu.org; 9 Dec 2020 11:02:29 +0000 Received: from localhost ([127.0.0.1]:32887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmxEq-0005O0-Rj for submit@debbugs.gnu.org; Wed, 09 Dec 2020 06:02:29 -0500 Received: from smtp-4.orcon.net.nz ([60.234.4.59]:41529) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmxEn-0005Nq-L3 for 45085@debbugs.gnu.org; Wed, 09 Dec 2020 06:02:27 -0500 Received: from [101.53.216.160] (port=44125 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1kmxEk-0002j4-Qk; Thu, 10 Dec 2020 00:02:23 +1300 Subject: Re: bug#45085: Have so-long mode fire-sprinkler system always ready for M-x compile, M-x shell To: =?UTF-8?B?56mN5Li55bC8IERhbiBKYWNvYnNvbg==?= , 45085@debbugs.gnu.org References: <87im9fuli6.5.fsf@jidanni.org> From: Phil Sainty Message-ID: <76bfb5aa-3bbf-3e0f-ccbc-08cbeff4668f@orcon.net.nz> Date: Thu, 10 Dec 2020 00:02:22 +1300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <87im9fuli6.5.fsf@jidanni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: On 7/12/20 2:12 am, 積丹尼 Dan Jacobson wrote: > so-long mode is great, when opening files. > But what about the case > (compile "perl -wle 'print 8 x 888888888;'")? > That's going to produce a buf [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [101.53.216.160 listed in zen.spamhaus.org] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [60.234.4.59 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -0.0 NICE_REPLY_A Looks like a legit reply (A) X-Debbugs-Envelope-To: 45085 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.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: On 7/12/20 2:12 am, 積丹尼 Dan Jacobson wrote: > so-long mode is great, when opening files. > But what about the case > (compile "perl -wle 'print 8 x 888888888;'")? > That's going to produce a buf [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [60.234.4.59 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [101.53.216.160 listed in zen.spamhaus.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (psainty[at]orcon.net.nz) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 NICE_REPLY_A Looks like a legit reply (A) On 7/12/20 2:12 am, 積丹尼 Dan Jacobson wrote: > so-long mode is great, when opening files. > But what about the case > (compile "perl -wle 'print 8 x 888888888;'")? > That's going to produce a buffer with a really long line. > So so-long mode should jump in to the rescue. > > And what about M-x shell? > If we do > $ perl -wle 'print 8 x 888888888;' One immediate issue with the scenario you're considering is that buffers handling process output are commonly auto-scrolling to the end of the output, which means that after running a command which produces a massive line, you're liable to be left with the *end* of the giant line visible in the window (which is the worst-case situation); so Emacs might struggle with that even if so-long was active. I do think it would be interesting to experiment with using `after-change-functions' to detect the insertion of extremely long lines into a buffer, but I also think it might bring significant complications, so I don't have any current plans to extend the library in these directions. We can be relatively confident about the suitability of calling `so-long' in a buffer which is visiting a file of programming code; but it's harder to have such confidence when considering buffers *generally* -- Emacs buffers can be used for almost anything, and it may be wildly inappropriate for `so-long' to get involved in many of those cases. Especially when considering buffers dealing with external processes, when the buffer's mode might be fairly generic, yet with a wide variety of different output possibilities. Explicit/white-listed uses of `so-long-minor-mode' can be useful, however. For example, I recall an Emacs 26 user reporting excellent performance improvements (albeit at the cost to the readability) from using `so-long-minor-mode' in debugger backtrace buffers when giant lists of text properties were involved; so there's certainly scope to use so-long outside of file-visiting buffers in particular scenarios; but my gut feeling is that such uses ought to be targeted individually. -Phil From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 09 07:51:45 2020 Received: (at 45085) by debbugs.gnu.org; 9 Dec 2020 12:51:45 +0000 Received: from localhost ([127.0.0.1]:32987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmywb-0001pL-4C for submit@debbugs.gnu.org; Wed, 09 Dec 2020 07:51:45 -0500 Received: from dormouse.elm.relay.mailchannels.net ([23.83.212.50]:27606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmywY-0001pC-NM for 45085@debbugs.gnu.org; Wed, 09 Dec 2020 07:51:43 -0500 X-Sender-Id: dreamhost|x-authsender|jidanni@jidanni.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 501C7641FD8; Wed, 9 Dec 2020 12:51:41 +0000 (UTC) Received: from pdx1-sub0-mail-a21.g.dreamhost.com (100-96-21-99.trex.outbound.svc.cluster.local [100.96.21.99]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D26FF64203A; Wed, 9 Dec 2020 12:51:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jidanni@jidanni.org Received: from pdx1-sub0-mail-a21.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.11); Wed, 09 Dec 2020 12:51:41 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jidanni@jidanni.org X-MailChannels-Auth-Id: dreamhost X-Dime-Harmony: 70898f1564b3025e_1607518301158_611344296 X-MC-Loop-Signature: 1607518301158:170128994 X-MC-Ingress-Time: 1607518301158 Received: from pdx1-sub0-mail-a21.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a21.g.dreamhost.com (Postfix) with ESMTP id 392B7891C7; Wed, 9 Dec 2020 04:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jidanni.org; h=from:to:cc :subject:references:date:message-id:mime-version:content-type; s=jidanni.org; bh=PENly5vFtBJ8TuDoingJNylv9Jk=; b=pZyuMwE+IiBdp WPFy6dkuLKsLEAx7RC/vyArUtIR+06KLS46neznzRXcBwRbtP563jeMpRg3Bu9B7 puttAYMeCc96iMvdbVh5hzGef7yOISo4TdeGEbmiciOoPL7XS6Zbr6QiI2mE+kcF gacuDydEW7lgdtcHAFF9xSeBKA98OY= Received: from jidanni.org (114-46-59-9.dynamic-ip.hinet.net [114.46.59.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jidanni@jidanni.org) by pdx1-sub0-mail-a21.g.dreamhost.com (Postfix) with ESMTPSA id 4F39880169; Wed, 9 Dec 2020 04:51:38 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a21 From: =?utf-8?B?56mN5Li55bC8?= Dan Jacobson To: Phil Sainty Subject: Re: bug#45085: Have so-long mode fire-sprinkler system always ready for M-x compile, M-x shell References: <87im9fuli6.5.fsf@jidanni.org> <76bfb5aa-3bbf-3e0f-ccbc-08cbeff4668f@orcon.net.nz> Date: Wed, 09 Dec 2020 20:51:34 +0800 Message-ID: <87y2i7gn1l.5.fsf@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 45085 Cc: 45085@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 (-) >>>>> "PS" == Phil Sainty writes: PS> One immediate issue with the scenario you're considering PS> is that buffers handling process output are commonly PS> auto-scrolling to the end of the output, which means that Got an idea: Guilty until proven innocent! E.g., when a *compilation* buffer is born, it should / could be in so-long mode at birth. And only when it is finished filling up, (compilation status: "exit") an (automatic) inspection could be made. And only if there were no crazy long lines in it, would so-long mode be lifted. Yes, there are long (many minutes) compilation jobs. Ones where the user is sure nothing will go wrong too. For them the user could set a variable... From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 23 06:35:12 2021 Received: (at 45085) by debbugs.gnu.org; 23 Oct 2021 10:35:12 +0000 Received: from localhost ([127.0.0.1]:34473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meEMq-0007TK-Au for submit@debbugs.gnu.org; Sat, 23 Oct 2021 06:35:12 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:39439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meEMk-0007Sa-Uj for 45085@debbugs.gnu.org; Sat, 23 Oct 2021 06:35:09 -0400 Received: by mail-pl1-f176.google.com with SMTP id t21so4489695plr.6 for <45085@debbugs.gnu.org>; Sat, 23 Oct 2021 03:35:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=mVt5Iecr3yv3emeYXmP/Jvmf7BzmBANNHq1A0FPS2jc=; b=bPruIs+0Oa0DxPYHcIo8GJnuuJvdvSF6FK88sEiNuHFzJ/npk4Y7Zaz8AmCLJaMrjW KefW44X8hyvbGzeVmbi3XYe/ZtahYFwce2waRg2HBNx432VJ6VKO7RmCbJo9rrBMj+Dk KvjaG+St3r+bjTetnIlxPs5PSUb7c7L0EWOZ2SZxKCBNJbHUY0WRkcER9bZCCrCPafGt UYidabI6qB+iGLXh8Z70tSnrc/Lgzj/YY63f/yS6Mcv7GVwGn9IHSvYV9cbqiPqdejut ybZ1XvBIOFKGZTnfXPEaTsiG4Tcmui16lk7bTE56kvYW4wir/wmxj7uteQEZnKlxL4s4 H9BA== X-Gm-Message-State: AOAM531Awr+bDmva9+vRDFBHEbBkGv6qVWjTLaByn26jfJckR/O6w4rT SWoStScWlWFWHnj88QfwUCjHLBLvv2cYEdpeNgc= X-Google-Smtp-Source: ABdhPJzbDmcxcb0k2OHvOEpJQ7ms+mbY00UeLJ/hfWOwHnB8yZYY8Xhr/7pIwTeFBs1CAT807iMklZjmMyVDR8mH4Oo= X-Received: by 2002:a17:902:e750:b0:140:2693:b2e8 with SMTP id p16-20020a170902e75000b001402693b2e8mr5009076plf.22.1634985301094; Sat, 23 Oct 2021 03:35:01 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 23 Oct 2021 03:35:00 -0700 From: Stefan Kangas In-Reply-To: <76bfb5aa-3bbf-3e0f-ccbc-08cbeff4668f@orcon.net.nz> (Phil Sainty's message of "Thu, 10 Dec 2020 00:02:22 +1300") References: <87im9fuli6.5.fsf@jidanni.org> <76bfb5aa-3bbf-3e0f-ccbc-08cbeff4668f@orcon.net.nz> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Date: Sat, 23 Oct 2021 03:35:00 -0700 Message-ID: Subject: Re: bug#45085: Have so-long mode fire-sprinkler system always ready for M-x compile, M-x shell To: Phil Sainty Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45085 Cc: 45085@debbugs.gnu.org, =?UTF-8?B?56mN5Li55bC8IERhbiBKYWNvYnNvbg==?= 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.5 (/) tags 45085 + wontfix close 45085 thanks Phil Sainty writes: > One immediate issue with the scenario you're considering > is that buffers handling process output are commonly > auto-scrolling to the end of the output, which means that > after running a command which produces a massive line, > you're liable to be left with the *end* of the giant line > visible in the window (which is the worst-case situation); > so Emacs might struggle with that even if so-long was > active. > > I do think it would be interesting to experiment with using > `after-change-functions' to detect the insertion of > extremely long lines into a buffer, but I also think it > might bring significant complications, so I don't have any > current plans to extend the library in these directions. > > We can be relatively confident about the suitability of > calling `so-long' in a buffer which is visiting a file of > programming code; but it's harder to have such confidence > when considering buffers *generally* -- Emacs buffers can be > used for almost anything, and it may be wildly inappropriate > for `so-long' to get involved in many of those cases. > Especially when considering buffers dealing with external > processes, when the buffer's mode might be fairly generic, > yet with a wide variety of different output possibilities. > > Explicit/white-listed uses of `so-long-minor-mode' can be > useful, however. For example, I recall an Emacs 26 user > reporting excellent performance improvements (albeit at the > cost to the readability) from using `so-long-minor-mode' in > debugger backtrace buffers when giant lists of text > properties were involved; so there's certainly scope to use > so-long outside of file-visiting buffers in particular > scenarios; but my gut feeling is that such uses ought to be > targeted individually. It seems like this is not something we want to do or even see as feasible. So I'm closing this as wontfix. If this conclusion is incorrect, please reply to this email (use "Reply to all" in your email client) and we can reconsider. From unknown Sat Aug 09 20:34:48 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 20 Nov 2021 12:24:08 +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