From unknown Sat Jun 21 03:21:21 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#56311 <56311@debbugs.gnu.org> To: bug#56311 <56311@debbugs.gnu.org> Subject: Status: [PATCH] new function: delete-visited-file Reply-To: bug#56311 <56311@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:21:21 +0000 retitle 56311 [PATCH] new function: delete-visited-file reassign 56311 emacs submitter 56311 Zachary Kanfer severity 56311 wishlist tag 56311 moreinfo wontfix patch thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 00:26:31 2022 Received: (at submit) by debbugs.gnu.org; 30 Jun 2022 04:26:31 +0000 Received: from localhost ([127.0.0.1]:60564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6ll9-00011S-Ay for submit@debbugs.gnu.org; Thu, 30 Jun 2022 00:26:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:39754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6ll4-00011I-Ol for submit@debbugs.gnu.org; Thu, 30 Jun 2022 00:26:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6ll2-0007G9-Pl for bug-gnu-emacs@gnu.org; Thu, 30 Jun 2022 00:26:26 -0400 Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]:38462) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o6ll0-0007RV-Cj for bug-gnu-emacs@gnu.org; Thu, 30 Jun 2022 00:26:24 -0400 Received: by mail-yb1-xb2d.google.com with SMTP id d5so31659672yba.5 for ; Wed, 29 Jun 2022 21:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=8SjkV+9LxV5FJLyFlJ9FoFe+dDLku+YMEetI+TG2Uo4=; b=MUbMIjE6cGbdOqPICt7SLhBINViog/o0HnW9bQxORHutyCf+0vgIPwFrqlss7lPEbk LgzCgd2qTP/SlobYmIMZFaL+d0wLCW7/ktwE3+DYYcSx2fvQ9gFdXNQf5DoY1Lk6zcSY E9b03k4BP413FzBP2998yQfuO6RdnsS4S0bsB9uXDUiCuwyxl/4X0qTERKFhubgAdEl7 Yes0Bea4apQQkXNp4JqWJMC4ngISR3YFc3iz3VV5aTqR0TeZVz0qU2TtJK4Q2b2ARJEg umhMnVQHfieQJo/OvgmNns9wEmS5lSKX0+M+jolM+VU1M6tbzfOuRwtdnWizTv1cVnz+ OOTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8SjkV+9LxV5FJLyFlJ9FoFe+dDLku+YMEetI+TG2Uo4=; b=TMfrAhpgfN+swYVCsfUxhDeDGcdalzABvzZxs3p3J3Q9b8pgjkGSDgXTAuq0lNZ2TP tYDTY2AvC7lip7Z2HEPlC1l1lWwt077I+jrmnumOQsCiWUOglmEn7443vzfVrDzsotq4 ynrCh7XtNvPw5n2YSFT0pPdRMBtR6m+JoiOPTpPsTwtHIZtcPBtnMhfdVPtCWO/hB2Ym tGmWPt+mU4Kr83HtU4q1PdadUN5B2Wa8p9n1wdLDV2wsYmC+kih1cdh3Y//ZLrs3ICjO IPxytZRkqO+3mE5cJ2BC+Pu7pe9lG3x8+nry5um8Z2rE4to6QfeUrSmy42aD2uFDMW6v GBYg== X-Gm-Message-State: AJIora92oFOVtZNuX/wIL6WEgRVCxO/g/CvICdiJA61ZZCY1UwJLUG7k ZswBfFTvFVfBGlLa/f8MvTvT1oe7mqItGl6vznx2KIbV X-Google-Smtp-Source: AGRyM1vs7aI/JwA2rx2vjiTu568gbPlmA7oMas1B/S1MWMVtZTpfanCpVIoNLmWXp0IPWaUNmW1SNz4BMfuKpVK1Vog= X-Received: by 2002:a05:6902:90e:b0:669:5bfb:9877 with SMTP id bu14-20020a056902090e00b006695bfb9877mr7423567ybb.323.1656563177537; Wed, 29 Jun 2022 21:26:17 -0700 (PDT) MIME-Version: 1.0 From: Zachary Kanfer Date: Thu, 30 Jun 2022 00:26:06 -0400 Message-ID: Subject: [PATCH] new function: delete-visited-file To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="000000000000bf092105e2a2abca" Received-SPF: pass client-ip=2607:f8b0:4864:20::b2d; envelope-from=zkanfer@gmail.com; helo=mail-yb1-xb2d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.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: -2.3 (--) --000000000000bf092105e2a2abca Content-Type: multipart/alternative; boundary="000000000000bf091e05e2a2abc8" --000000000000bf091e05e2a2abc8 Content-Type: text/plain; charset="UTF-8" When I delete a file, I almost always want the buffer visiting it to go away also. Why keep it around? So I have to do the following steps: 1. M-x delete-file 2. navigate to the file, select it. 3. C-x k So I wrote a function to delete the file a buffer is visiting, and close the buffer. Now I do everything in a single logical action: 1. M-x delete-visited-file 2. select the buffer. Patch is attached. --000000000000bf091e05e2a2abc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When I delete a file, I almost always want the buffer= visiting it to go away also. Why keep it around? So I have to do the follo= wing steps:

1. M-x delete-file
2. navigate to the file, select it= .
3. C-x k <ret>

So I wrote a function to delete the file= a buffer is visiting, and close the buffer. Now I do everything in a singl= e logical action:

1. M-x delete-visited-file
2. select the b= uffer.

Patch is attached.
--000000000000bf091e05e2a2abc8-- --000000000000bf092105e2a2abca Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Add-new-function-delete-visited-file.patch" Content-Disposition: attachment; filename="0001-Add-new-function-delete-visited-file.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l50iuww90 RnJvbSA3Y2U5MTMwMTNhMDIyZWM4NGIxMWYzYWJjMjJiYzgyZTA2ODI1ZjFlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYWNoYXJ5IEthbmZlciA8emthbmZlckBnbWFpbC5jb20+CkRh dGU6IFRodSwgMzAgSnVuIDIwMjIgMDA6MjE6MDEgLTA0MDAKU3ViamVjdDogW1BBVENIXSBBZGQg bmV3IGZ1bmN0aW9uIGRlbGV0ZS12aXNpdGVkLWZpbGUuCgoqIGxpc3AvZmlsZXMuZWwgKGRlbGV0 ZS12aXNpdGVkLWZpbGUpIE5ldyBjb21tYW5kCgoqIGRvYy9lbWFjcy9maWxlcy50ZXhpIChNaXNj ZWxsYW5lb3VzIEZpbGUgT3BlcmF0aW9ucyk6IERvY3VtZW50IGl0LgotLS0KIGRvYy9lbWFjcy9m aWxlcy50ZXhpIHwgIDIgKysKIGV0Yy9ORVdTICAgICAgICAgICAgIHwgIDUgKysrKysKIGxpc3Av ZmlsZXMuZWwgICAgICAgIHwgMTEgKysrKysrKysrKysKIDMgZmlsZXMgY2hhbmdlZCwgMTggaW5z ZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2RvYy9lbWFjcy9maWxlcy50ZXhpIGIvZG9jL2VtYWNz L2ZpbGVzLnRleGkKaW5kZXggZmEwMmQyNjRmOS4uNGJmZGExODJiNCAxMDA2NDQKLS0tIGEvZG9j L2VtYWNzL2ZpbGVzLnRleGkKKysrIGIvZG9jL2VtYWNzL2ZpbGVzLnRleGkKQEAgLTE5MzAsNiAr MTkzMCw4IEBAIE1pc2MgRmlsZSBPcHMKIGV4ZWN1dGlvbiBwZXJtaXNzaW9uIGZvciB0aGUgdXNl ciB3aG8gb3ducyB0aGUgZmlsZS4gIEl0IGhhcyBubyBlZmZlY3QKIG9uIG9wZXJhdGluZyBzeXN0 ZW1zIHRoYXQgZG8gbm90IHN1cHBvcnQgZmlsZSBtb2Rlcy4gIEBjb2Rle2NobW9kfSBpcyBhCiBj b252ZW5pZW5jZSBhbGlhcyBmb3IgdGhpcyBmdW5jdGlvbi4KK0BmaW5kZXggZGVsZXRlLXZpc2l0 ZWQtZmlsZQorICBAa2Jke2RlbGV0ZS12aXNpdGVkLWZpbGV9IGRlbGV0ZXMgdGhlIGZpbGUgdmlz aXRlZCBieSBhIGJ1ZmZlciwgYW5kIGNsb3NlcyB0aGUgYnVmZmVyLgogCiBAbm9kZSBDb21wcmVz c2VkIEZpbGVzCiBAc2VjdGlvbiBBY2Nlc3NpbmcgQ29tcHJlc3NlZCBGaWxlcwpkaWZmIC0tZ2l0 IGEvZXRjL05FV1MgYi9ldGMvTkVXUwppbmRleCBjZTMyNTQyMDI4Li5iNTUyNGQzNWZkIDEwMDY0 NAotLS0gYS9ldGMvTkVXUworKysgYi9ldGMvTkVXUwpAQCAtMzU1LDYgKzM1NSwxMSBAQCBtYXRj aCB0aG9zZSByZWdleHBzIHdpbGwgYmUgaWdub3JlZCBieSAnc3dpdGNoLXRvLXByZXYtYnVmZmVy JyBhbmQKIFRoaXMgY29tbWFuZCByZW5hbWVzIHRoZSBmaWxlIHZpc2l0ZWQgYnkgdGhlIGN1cnJl bnQgYnVmZmVyIGJ5IG1vdmluZwogaXQgdG8gYSBuZXcgbG9jYXRpb24sIGFuZCBhbHNvIG1ha2Vz IHRoZSBidWZmZXIgdmlzaXQgdGhpcyBuZXcgZmlsZS4KIAorKysrCisqKiBOZXcgY29tbWFuZCAn ZGVsZXRlLXZpc2l0ZWQtZmlsZScuCitUaGlzIGNvbW1hbmQgZGVsZXRlcyB0aGUgZmlsZSB2aXNp dGVkIGJ5IGEgYnVmZmVyLCB0aGVuIGNsb3NlcyB0aGUKK2J1ZmZlci4KKwogKiogTWVudXMKIAog LS0tCmRpZmYgLS1naXQgYS9saXNwL2ZpbGVzLmVsIGIvbGlzcC9maWxlcy5lbAppbmRleCAxMjk1 YzI0YzkzLi5mNWQ1MTJkNmJlIDEwMDY0NAotLS0gYS9saXNwL2ZpbGVzLmVsCisrKyBiL2xpc3Av ZmlsZXMuZWwKQEAgLTYyNjcsNiArNjI2NywxNyBAQCBkZWxldGUtZGlyZWN0b3J5CiAJCSAgZGly ZWN0b3J5LWV4aXN0cykpCiAJKGZpbGVzLS1mb3JjZSByZWN1cnNpdmUgIydkZWxldGUtZGlyZWN0 b3J5LWludGVybmFsIGRpcmVjdG9yeSkpKSkpKQogCisoZGVmdW4gZGVsZXRlLXZpc2l0ZWQtZmls ZSAoYnVmZmVyLW5hbWUpCisgICJEZWxldGUgdGhlIGZpbGUgdmlzaXRlZCBieSBidWZmZXIgQlVG RkVSLU5BTUUsIHRoZW4gY2xvc2UgdGhlIGJ1ZmZlci4iCisgIChpbnRlcmFjdGl2ZSAiYkRlbGV0 ZSBmaWxlIHZpc2l0ZWQgYnkgYnVmZmVyICIpCisgIChsZXQqICgoYnVmZmVyIChnZXQtYnVmZmVy IGJ1ZmZlci1uYW1lKSkKKyAgICAgICAgIChmaWxlbmFtZSAoYnVmZmVyLWZpbGUtbmFtZSBidWZm ZXIpKSkKKyAgICAod2hlbiBidWZmZXIKKyAgICAgICh3aGVuIChhbmQgZmlsZW5hbWUKKyAgICAg ICAgICAgICAgICAgKGZpbGUtZXhpc3RzLXAgZmlsZW5hbWUpKQorICAgICAgICAoZGVsZXRlLWZp bGUgZmlsZW5hbWUpKQorICAgICAgKGtpbGwtYnVmZmVyIGJ1ZmZlcikpKSkKKwogKGRlZnVuIGZp bGUtZXF1YWwtcCAoZmlsZTEgZmlsZTIpCiAgICJSZXR1cm4gbm9uLW5pbCBpZiBmaWxlcyBGSUxF MSBhbmQgRklMRTIgbmFtZSB0aGUgc2FtZSBmaWxlLgogSWYgRklMRTEgb3IgRklMRTIgZG9lcyBu b3QgZXhpc3QsIHRoZSByZXR1cm4gdmFsdWUgaXMgdW5zcGVjaWZpZWQuIgotLSAKMi4yNS4xCgo= --000000000000bf092105e2a2abca-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 01:30:12 2022 Received: (at 56311) by debbugs.gnu.org; 30 Jun 2022 05:30:12 +0000 Received: from localhost ([127.0.0.1]:60774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6mkm-00035C-DY for submit@debbugs.gnu.org; Thu, 30 Jun 2022 01:30:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43272) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6mki-00033n-Py for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 01:30:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43632) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6mkd-00018O-A8; Thu, 30 Jun 2022 01:30:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5az9IVPZtZKqD1t6hQtFkoAhOPfKVi2kiDmEHO1zLAg=; b=f8GHO3FWY4FX 9347NTRIX37axd1ODRl0wCLI0PIrongp67Igu0NQRPXmhcEic9YokuwvHPZjhvQMVtrkYSxsZs9hj Zr7cc+a/Tnos94uFZqkF3XiETznMbKzTuLvRn7x4ADbK20MB4s2KhgGKyO8QKM+GZ8QYWOAy8USQ7 5S7NquHwMzv3HKpmHk2gWXCH9M0X+/75RQp5reCwrDY0jyZHgfxuLa2KW88QQ/9amDvGb7Civrb+a A9PqsakW5owoyo4r+37W4TCgRq13mlKYDhg1NkkxBehs6zMrbOcpFRJCo8/Hs+U70UqzHBUAsOxyG FRwl32/ktZXi1lDTo/MW1A==; Received: from [87.69.77.57] (port=3989 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6mkc-0007LZ-9r; Thu, 30 Jun 2022 01:30:02 -0400 Date: Thu, 30 Jun 2022 08:30:10 +0300 Message-Id: <83k08y67ml.fsf@gnu.org> From: Eli Zaretskii To: Zachary Kanfer In-Reply-To: (message from Zachary Kanfer on Thu, 30 Jun 2022 00:26:06 -0400) Subject: Re: bug#56311: [PATCH] new function: delete-visited-file References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56311 Cc: 56311@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: -3.3 (---) > From: Zachary Kanfer > Date: Thu, 30 Jun 2022 00:26:06 -0400 > > +** New command 'delete-visited-file'. > +This command deletes the file visited by a buffer, then closes the > +buffer. "Close the buffer" is not our terminology, you won't find it in our documentation. We say "kill the buffer". I also think "delete-visited-file" is not the best name for the command, since it doesn't tell all the truth about what it does. Apart of that, I have no opinion about this proposal, although each time I see suggestions for features to kill unused buffers or see people who are worried about such buffers, I raise a brow: in Emacs, we generally don't care about that (because it does no harm to have unused buffers), and if someone's usage patterns are such that they tend to create _gobs_ of large buffers most of which quickly become unused, there's midnight.el to take care of that. But if the ultimate decision is to add this command, please keep it out of files.el, because that's a preloaded package, and thus it will increase the memory footprint of every Emacs session for the benefit of a command that I don't think is important enough. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 01:49:56 2022 Received: (at 56311) by debbugs.gnu.org; 30 Jun 2022 05:49:56 +0000 Received: from localhost ([127.0.0.1]:60797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6n3s-0003jX-26 for submit@debbugs.gnu.org; Thu, 30 Jun 2022 01:49:56 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:45423) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6n3p-0003jH-ET for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 01:49:54 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4E8635C0453; Thu, 30 Jun 2022 01:49:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 30 Jun 2022 01:49:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1656568188; x=1656654588; bh=Ls zQXSsZ/way8Kehh1G7DjPnkuKW+smS1KCvjAhg0Fg=; b=j6+QWa/RC5hMtN3jZz gt8UTTj5VAmY6NmFQVL9iE1P9pZ+L6f1+pnKj/mOpLzKYw3yTsHc6L4/L01g5ME+ v5QQNEV12vD0gvxFizdfgC2MCPpCF8Lq1COeFFz3tUEt9WiCmdGh0TozYXKhPmo0 ig2A4lAGXQQi4MFO3nHIYOs4v3MvqvUcINuNZxMlLfrut8XVuhSgSxGo/jz+6ObO mN8x8aRvOMd0Q1VH0zLfIiNL8ZwpVJF3sP7UYN6p97R6AUTMIErloWo96on8NL3s xaQtxqhAtgZp11oPNYAuMdBLZJ6Y83XEI6KJkLbWQ94sPSe3pjjwM6oVKkkQ79U1 Vfjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1656568188; x=1656654588; bh=LszQXSsZ/way8Kehh1G7DjPnkuKW +smS1KCvjAhg0Fg=; b=qb8qzUAVMTFVvCOHCe7Jghjt5X4tzK24VKNUR2glvioC iqGzXx73Aw9bPRnz5nV5jsONwPzHh6Dlm1tgryDLJCM3f0qRlkNmWRbVYZv7ySYk F9a7jQKL3hc1C2h7QhZKEFw0ZVm3dDf5+PMn+j9p3oWiGKDEO/eSNAAicdC58r8c dMP0WgvM9Qxpyu5roq5iO1/Hgkc7NzLDxV8pOztST2ON6VOo2c31DDgQ3khyTKln rT+U1tQB+AmOGCmfdb9DPWVs5PRJeKn0acCOvRb0x9RJkqkUpSVo8DZi1k73d057 FPuEWt+pRnpT4XkjQxskioKatdV8FTuL4ocqayJ3DA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudehtddguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufgjfhgffffkgggtsehttddttddtredtnecuhfhrohhmpefuvggr nhcuhghhihhtthhonhcuoehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvg eqnecuggftrfgrthhtvghrnhepvdejtedtieetjeegjeekgffghedtkeeltdeftdetkefg ueekfedtudfhteeljeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepshhpfihhihhtthhonhesshhpfihhihhtthhonhdrnhgrmhgv X-ME-Proxy: Feedback-ID: i23c04076:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Jun 2022 01:49:47 -0400 (EDT) Received: by athena.silentflame.com (Postfix, from userid 1000) id 2C56B1B5CB8; Thu, 30 Jun 2022 05:49:47 +0000 (UTC) From: Sean Whitton To: Eli Zaretskii , Zachary Kanfer Subject: Re: bug#56311: [PATCH] new function: delete-visited-file In-Reply-To: <83k08y67ml.fsf@gnu.org> References: <83k08y67ml.fsf@gnu.org> User-Agent: Notmuch/0.36 Emacs/29.0.50 (x86_64-pc-linux-gnu) Date: Wed, 29 Jun 2022 22:49:47 -0700 Message-ID: <87tu82bszo.fsf@athena.silentflame.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 56311 Cc: 56311@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.7 (-) Hello, On Thu 30 Jun 2022 at 08:30am +03, Eli Zaretskii wrote: >> From: Zachary Kanfer >> Date: Thu, 30 Jun 2022 00:26:06 -0400 >> >> +** New command 'delete-visited-file'. >> +This command deletes the file visited by a buffer, then closes the >> +buffer. > > "Close the buffer" is not our terminology, you won't find it in our > documentation. We say "kill the buffer". > > I also think "delete-visited-file" is not the best name for the > command, since it doesn't tell all the truth about what it does. > > Apart of that, I have no opinion about this proposal, although each > time I see suggestions for features to kill unused buffers or see > people who are worried about such buffers, I raise a brow: in Emacs, > we generally don't care about that (because it does no harm to have > unused buffers), and if someone's usage patterns are such that they > tend to create _gobs_ of large buffers most of which quickly become > unused, there's midnight.el to take care of that. I don't care about the buffer being killed either, but there isn't currently a quick way to delete the file the selected buffer is visiting, you have to type/complete its name. It would be nice to have that, which I think this command provides. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 01:56:09 2022 Received: (at 56311) by debbugs.gnu.org; 30 Jun 2022 05:56:09 +0000 Received: from localhost ([127.0.0.1]:60807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6n9t-0003uA-4l for submit@debbugs.gnu.org; Thu, 30 Jun 2022 01:56:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6n9s-0003tx-27 for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 01:56:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43848) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6n9m-0000gt-Oa; Thu, 30 Jun 2022 01:56:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nlNff6P9p8NOxVViGp9K6MoIcXLbEPgc0lXpxT74d+g=; b=Zv3FKTyqt9K4 NPjFAwIEATkTX150JByzKTOSnIpvZolCBQysw2OsZ2iGgNXyn2wMBPP/aMpbgPbyFTIbQSIdDhP2Z 73VFhfuhBBggEVxxJ9gnktI8r5zvZ0SFq9l2oslvanUCd48FZ2/lfOokwWGdWjCp6YHxiEj5oCBKm wgi3ggI/J14xcqudlkrn5+Q6iQ2xvtWeGZk0iK3avZgpYAu8TCXWNfvTU+LTKvlJNu0X/6ASMhXc6 45b1pdiOKil7EU+kGWoNAzh9swGcWhRqSBzkcb2+8r/KqyutfA6KRKb603WQVFoGJ8XUmzIVUEO1O DHcjTxO7NxTE2bvpgky/DQ==; Received: from [87.69.77.57] (port=1613 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o6n9k-0003QL-R9; Thu, 30 Jun 2022 01:56:02 -0400 Date: Thu, 30 Jun 2022 08:56:08 +0300 Message-Id: <83h74266fb.fsf@gnu.org> From: Eli Zaretskii To: Sean Whitton In-Reply-To: <87tu82bszo.fsf@athena.silentflame.com> (message from Sean Whitton on Wed, 29 Jun 2022 22:49:47 -0700) Subject: Re: bug#56311: [PATCH] new function: delete-visited-file References: <83k08y67ml.fsf@gnu.org> <87tu82bszo.fsf@athena.silentflame.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56311 Cc: zkanfer@gmail.com, 56311@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: -3.3 (---) > From: Sean Whitton > Cc: 56311@debbugs.gnu.org > Date: Wed, 29 Jun 2022 22:49:47 -0700 > > I don't care about the buffer being killed either, but there isn't > currently a quick way to delete the file the selected buffer is > visiting, you have to type/complete its name. No, you don't: M-x delete-file RET M-n RET From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 02:21:02 2022 Received: (at 56311) by debbugs.gnu.org; 30 Jun 2022 06:21:02 +0000 Received: from localhost ([127.0.0.1]:60840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6nXy-0004c3-Eu for submit@debbugs.gnu.org; Thu, 30 Jun 2022 02:21:02 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:40566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6nXv-0004bB-4k for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 02:21:01 -0400 Received: by mail-pg1-f193.google.com with SMTP id 9so17540956pgd.7 for <56311@debbugs.gnu.org>; Wed, 29 Jun 2022 23:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=L3PnxtQiL+XjIOs9KvJXryC/Ew2LCWIzdDfCvXXrk+c=; b=Uuh47/y+Kt/r4Z7hXJ8SpxyEM2FTTB4mPEztHU9t68zPfkJsZwSfW/MjhDDo09YfR7 +Yy01IxbNWe6624seHV+1lD/BgPvFD6qID+a+uS+RWVSL84vKW2aI0prJYHtpETvflpT YEsx+2jX218OksBeDEQlHZh8XiK+9KmuNMY2UIzadi9rygtahj1+AXnjfpOfeo0OqGz1 H6WhPO+OHTmMq3mTF1UCoBL6TXt3NQKkCFN4r+u2bKiiXwO3EytDwF5sV1vgrzl5YZx0 FSGF7Z8bdw8TVA4G87H2QHVsk9WXFLQm5hb2ozeyd0vBnNZwTg72XUlUOSnyZth4NvXj 1tbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=L3PnxtQiL+XjIOs9KvJXryC/Ew2LCWIzdDfCvXXrk+c=; b=DswvRHDdQBNnFznv3Pkw4H7GM/u+zY7/Sgyna8QjWVt9F1u5Kudx3DBbo1DyS39thf 1rgBj0Dq8nKqhnxmW2yJwqe9kuJhyXXsvVLRxXxwnZ/TCNgfAltEw6xvwFvY26vXYtM8 glJ0E0Xt6IQ8eaQkz3hzPaLUfHDkNXO4EXZaC792iQ01ay8k2Y/xTAsqz9f4zt1fWF5E uzffv30TgEMKCxm7NgDYkc4Mzu3tVd5JMvjh7h5Mg/hLd5Pz/JDSPlLWZYsBjWeRBJPM RIgSDKCP3Uw88oMKUiILfwTpWLVaWNON7w3+ueAfSxz9whrjxV34cPM7t3p1DG+2t8rE E8Zg== X-Gm-Message-State: AJIora/U8+wr4bHNwsx3mzmWs50ALtro1SmBLN9J4axcr4ovTkEui6qu /CwMDIqbK192TSuxdmsveTg= X-Google-Smtp-Source: AGRyM1sypIY3mDfyxw5tzmt+DN6PvwmFajbvlTaeDII0Y+lvtEmCSAjFnOB5MnIPn9d3tYyq2ZbslQ== X-Received: by 2002:a63:1259:0:b0:40d:d290:24ef with SMTP id 25-20020a631259000000b0040dd29024efmr6322699pgs.141.1656570053342; Wed, 29 Jun 2022 23:20:53 -0700 (PDT) Received: from localhost ([49.204.135.0]) by smtp.gmail.com with ESMTPSA id c126-20020a621c84000000b005252defb016sm12639880pfc.122.2022.06.29.23.20.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jun 2022 23:20:52 -0700 (PDT) From: Visuwesh To: Eli Zaretskii Subject: Re: bug#56311: [PATCH] new function: delete-visited-file References: <83k08y67ml.fsf@gnu.org> Date: Thu, 30 Jun 2022 11:50:50 +0530 In-Reply-To: <83k08y67ml.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Jun 2022 08:30:10 +0300") Message-ID: <87wncyr7st.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56311 Cc: Zachary Kanfer , 56311@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 (-) [=E0=AE=B5=E0=AE=BF=E0=AE=AF=E0=AE=BE=E0=AE=B4=E0=AE=A9=E0=AF=8D =E0=AE=9C= =E0=AF=82=E0=AE=A9=E0=AF=8D 30, 2022] Eli Zaretskii wrote: > Apart of that, I have no opinion about this proposal, although each > time I see suggestions for features to kill unused buffers or see > people who are worried about such buffers, I raise a brow: in Emacs, > we generally don't care about that (because it does no harm to have > unused buffers), and if someone's usage patterns are such that they > tend to create _gobs_ of large buffers most of which quickly become > unused, there's midnight.el to take care of that. FWIW, the fact that Emacs leaves the buffer around has saved my back at least twice, . when I accidentally deleted the wrong files in dired due to stale marks. . when I tried to fix a broken symlink but got the argument order in ln wrong and had the real file "zeroed". From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 06:27:34 2022 Received: (at 56311) by debbugs.gnu.org; 30 Jun 2022 10:27:34 +0000 Received: from localhost ([127.0.0.1]:32968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6rOY-0005gD-91 for submit@debbugs.gnu.org; Thu, 30 Jun 2022 06:27:34 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6rOX-0005fw-6S for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 06:27:33 -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:Date:References: In-Reply-To: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=1wDO9bJEtWeufH/kh1ADrzNne8oXxdwHz9PLBG0gS3I=; b=Z2kLSepy6bA+vuIMjQ0MkiyIIb oZ4od5fEbaQt8743BMbT8EnzNVo3oEwmO94qE/++ejrsQxIt+NJ/VK5treUnM9gaJsxBCJyESNT/X SBN3IMiep8ZxNtmsApxCXEuwsjsyhkchjzCKMGECwtzioJP/wAnrAGaYcCaCkLwePwMo=; Received: from [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 1o6rOO-0002Go-Kc; Thu, 30 Jun 2022 12:27:27 +0200 From: Lars Ingebrigtsen To: Visuwesh Subject: Re: bug#56311: [PATCH] new function: delete-visited-file In-Reply-To: <87wncyr7st.fsf@gmail.com> (Visuwesh's message of "Thu, 30 Jun 2022 11:50:50 +0530") References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> X-Now-Playing: Andrew Poppy's _The Beating of Wings_: "Cadenza" Date: Thu, 30 Jun 2022 12:27:24 +0200 Message-ID: <87wncybg4z.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.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: Visuwesh writes: > FWIW, the fact that Emacs leaves the buffer around has saved my back at > least twice, > > . when I accidentally deleted the wrong files in dired due to > stale marks. > . when I tried to fix a brok [...] 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: 56311 Cc: Eli Zaretskii , Zachary Kanfer , 56311@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: -3.3 (---) Visuwesh writes: > FWIW, the fact that Emacs leaves the buffer around has saved my back at > least twice, > > . when I accidentally deleted the wrong files in dired due to > stale marks. > . when I tried to fix a broken symlink but got the argument order in > ln wrong and had the real file "zeroed". And since deleting the visited file is currently very easy, as Eli pointed out: M-x delete-file RET M-n RET I don't think this would be a command that people would use a lot. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 06:27:39 2022 Received: (at control) by debbugs.gnu.org; 30 Jun 2022 10:27:39 +0000 Received: from localhost ([127.0.0.1]:32971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6rOd-0005ga-HW for submit@debbugs.gnu.org; Thu, 30 Jun 2022 06:27:39 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6rOb-0005g4-Qt for control@debbugs.gnu.org; Thu, 30 Jun 2022 06:27:38 -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=x04ZeQw3VVM+GmckpK2DxtpcLsowa/X/1mAqfimADwM=; b=KdMIF66XHuh6UMhK8vkndhIC4H DQI2OYKXS2Q5bnWalSNgTRXdjVcPEIjp0Ii76ETu0CisXPiSYWvecj5utefM+BHdr95bZon8z2D0b Wjfvj2PmuzEInVNLD/COzPycXRjEuOVdTmAx8BNY3rBr2dJmuIoESMl1Q1TWaj4lSHc4=; Received: from [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 1o6rOU-0002Gv-1W for control@debbugs.gnu.org; Thu, 30 Jun 2022 12:27:32 +0200 Date: Thu, 30 Jun 2022 12:27:29 +0200 Message-Id: <87v8sibg4u.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #56311 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 56311 + moreinfo 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 (---) tags 56311 + moreinfo quit From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 12:29:25 2022 Received: (at 56311) by debbugs.gnu.org; 30 Jun 2022 16:29:25 +0000 Received: from localhost ([127.0.0.1]:35406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6x2f-00064W-PS for submit@debbugs.gnu.org; Thu, 30 Jun 2022 12:29:25 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:35909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o6x2a-00064E-PZ for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 12:29:20 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AFA3F3200B17; Thu, 30 Jun 2022 12:29:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 30 Jun 2022 12:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1656606550; x=1656692950; bh=z+ 7Mg0ZAxlCpVVCc1SRHNn7TA72bHu9fECqrw7a84W8=; b=efQAqDSmYxkIzvdqz3 v5c+C75Mqubqg+lupxx8LoTFe47XHkSzDmYzCHnjDjRj8HBp2+4DGemlW0WoW/Jp LPYRAUiWEZQ5xUFxvEnWUfJKPr2amyQIv0+oBq4fK8cnDFMUQCECH/oyRSwbeHM5 CdpyTpeo9pmkNxN/TXWYvDTplaqBkJ4fXECdIBfD1T3fRyhqUHPBRGoWvqzBHbUJ zVkNOZapWXkRHVKLL4z6/2ba7dzuqq+vbyvIUUBhFE364HXFBl3jWGWpGLP0IJss TPCX5K7XS4Daa2IT9lOQGE0LUpJmU1B68pR90AtAJPOKDvzHWs3utUjaH+EbIGga iIQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1656606550; x=1656692950; bh=z+7Mg0ZAxlCpVVCc1SRHNn7TA72b Hu9fECqrw7a84W8=; b=GtZ6hl1RNdIVJzRO/JUCDkH2JkStduMHJ86gn4F1tlxh rlWkEVcW/mWR36l4kklorG2hXMDJxjEZIgm1G2Upxb3uxF4FVEV46IzQL0V4qWtD hBZmul7A2RHlcVebLblp9VTwhWB2eeKqrabbXkkNVZ/arRBEBQ15GT4s+EsJ1qXp 1/68fsHOIjlxgi3XKZKoNkjv9vOGHrEHEDRjWQ/U7aacL8YhR1D6/5QJh7Y0YxKd WpVad45KAaGdjVe4taeRfbau+OhKiVnfvJ9tzVT9gvg13Ks7PJsqh9q0bH0ouQ56 o48GmH3Ls4CrLQchYI5eM8FsmoxL7wssNDb3CtngAg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudehuddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffgffkfggtgesthdttddttdertdenucfhrhhomhepufgvrghn ucghhhhithhtohhnuceoshhpfihhihhtthhonhesshhpfihhihhtthhonhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpedvjeettdeiteejgeejkefggfehtdekledtfedtteekgfeu keeftdduhfetleejkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvg X-ME-Proxy: Feedback-ID: i23c04076:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Jun 2022 12:29:09 -0400 (EDT) Received: by athena.silentflame.com (Postfix, from userid 1000) id 2A3A61B5880; Thu, 30 Jun 2022 16:29:08 +0000 (UTC) From: Sean Whitton To: Lars Ingebrigtsen , Visuwesh Subject: Re: bug#56311: [PATCH] new function: delete-visited-file In-Reply-To: <87wncybg4z.fsf@gnus.org> References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> User-Agent: Notmuch/0.36 Emacs/29.0.50 (x86_64-pc-linux-gnu) Date: Thu, 30 Jun 2022 09:29:08 -0700 Message-ID: <87r136aze3.fsf@athena.silentflame.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 56311 Cc: Eli Zaretskii , Zachary Kanfer , 56311@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.7 (-) Hello, On Thu 30 Jun 2022 at 12:27pm +02, Lars Ingebrigtsen wrote: > And since deleting the visited file is currently very easy, as Eli > pointed out: > > M-x delete-file RET M-n RET There's also C-x C-j D. > I don't think this would be a command that people would use a lot. They shouldn't be using it a lot, and I agree that it probably shouldn't be added, but it does seem worth noting that a lot of users have something like this in their init, and use it a lot. I did until today, and used it almost daily. (After reading this thread, I've replaced it with something calling bury-buffer.) It's also to be found in Spacemacs and Doom Emacs. -- Sean Whitton From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 16:53:05 2022 Received: (at control) by debbugs.gnu.org; 30 Jun 2022 20:53:05 +0000 Received: from localhost ([127.0.0.1]:35740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o719t-0001Nh-CY for submit@debbugs.gnu.org; Thu, 30 Jun 2022 16:53:05 -0400 Received: from mail-pg1-f180.google.com ([209.85.215.180]:42576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o719p-0001MN-AS for control@debbugs.gnu.org; Thu, 30 Jun 2022 16:53:01 -0400 Received: by mail-pg1-f180.google.com with SMTP id d129so446781pgc.9 for ; Thu, 30 Jun 2022 13:53:01 -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:mime-version:date:message-id:subject:to; bh=lXojnYbEkKv/NFV2oxDkO/RDyAApk5FCWJFObKaDf7E=; b=DLNbhs9qD8Ib0deeeghSz4Ho86Nd2vF5xDKdlZhm6cIlspmLOVuRHCwdBFzELC6tuj qNxbAo/1Esz+XKFQ6xKlZduvjJLrY/k6+bUgssHh/21NWF1mj3lO7/NQhv5YLKzD0TVy Y1robQ2YPfn7rCkGMc/CFTHUL3zCSqyQhIIqT2aJ57zuCGj9OxRNdaPF+wvIW6/qSOH+ zeM03XpWgbxqtdZGCdDaqlOtzvz/WG9aMEdfZOdcX99c3C8VET+hjtalZ8ZmlhXnQrDk q5TjXvM94fuu3nCEdM2ZAfA+45S2PGqDCtmdT5P8aYHfZKM9MSKz4tQaBQaBXNHtb5gK HXkg== X-Gm-Message-State: AJIora9wD/TC29E/r+ydUttW+Ji0ykUjK4ASJOuIYJS3gsJuPFs6mqAj g37VBJ17nuu0JLJiDnlz29zaiyTeUGYSY+ATbs9jaRXW X-Google-Smtp-Source: AGRyM1srbVxjy9Vp4OYkJ2Y+mR32cgk0gJxNkWbVczfA4Qbx6gvyK9LP24Yt3ucsfo77F9jmPspo5E+Zk6atLaLj5cw= X-Received: by 2002:aa7:804e:0:b0:528:1672:215f with SMTP id y14-20020aa7804e000000b005281672215fmr4339310pfm.3.1656622375659; Thu, 30 Jun 2022 13:52:55 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 30 Jun 2022 13:52:55 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Thu, 30 Jun 2022 13:52:55 -0700 Message-ID: Subject: control message for bug #56311 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) 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: -0.5 (/) severity 56311 wishlist quit From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 30 23:29:55 2022 Received: (at 56311) by debbugs.gnu.org; 1 Jul 2022 03:29:55 +0000 Received: from localhost ([127.0.0.1]:36006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o77Lv-0001K0-DE for submit@debbugs.gnu.org; Thu, 30 Jun 2022 23:29:55 -0400 Received: from mail-yb1-f170.google.com ([209.85.219.170]:43975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o77Lt-0001Jk-9H for 56311@debbugs.gnu.org; Thu, 30 Jun 2022 23:29:54 -0400 Received: by mail-yb1-f170.google.com with SMTP id q132so1833752ybg.10 for <56311@debbugs.gnu.org>; Thu, 30 Jun 2022 20:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1a7FTtbKOOg18BrHnoTHvtEtePZ2oWxlIZ+TyOL1vxg=; b=YJ6BdVZjywPNaonMrP5eL2E1j4mg5bSkhyxXdGaTyH6d2TceoDSqpgrOS9RRTbPqy7 axRJDfotW9aUPyQ0AsoVO73zctTpxb1G1T7LTEnxsSfnoB6Ro6gUrGU6HUqBzxSH1m8c Pb7iXW2SDvabqn4f6MAndV/rb4Z1cv1ZO4ToLm6dEy0pxODUlR6dD2DPdFs4yo8q0jY6 lYpZOf4KqOsAOoqzCYl6qnLRZ5ezdbgr9OCi+XUKo2JXs0PBGD0j8Hp0UpHxWFqGt8+6 RgT6MFcdxoE4MBMnhUvManSaNgNq5cptvlPJ+uR5pC+YxlbHjW21mdfLzWuLjLDsua2h DuoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1a7FTtbKOOg18BrHnoTHvtEtePZ2oWxlIZ+TyOL1vxg=; b=8SFLjCeCWll4vVS7O78Lso2eNiHONzzoSE+vK8n9LZUwt2DdvereAUVEdUep3pKVVh y3h8/tKfKo7QXZyX0zSeK497XCvy37OTrAjrvP1+zZe71uVpQr1SglYEwKIGSJzZfaBr ZfQ4lau5Tw4h0AOHe+c4ECKHVQTskUTkg3yJyAVbNcA+E9Chwu96v2wWhFRBJjpMFxPY 8KL3sOpHqpMNEm2UzRjy70IgtwQ5K0qlNZGqtfBr9Q57Nm3iz6+1nimoYSueIRbJ3vmR rFeX8EC4HNFPyZBM5sSIdqLsOLtqKzMBzfbwYH5apqDp+TbFNBHE3u+bSu2BfIb2w1p7 8OyA== X-Gm-Message-State: AJIora+EeRCzzTaPPbSgMmh6LYpb4Hws8ANG0s2dLGB0EU7b9nGvuDhK TofnxbVqXpF2OD8cWYgL3Ug0HuPetJrjuGvwC8A= X-Google-Smtp-Source: AGRyM1vhp8yobum1aOsQzJSwM+FakDexBfPfx03HdJpN8s8kw7Mmp7PywYHodAY4Twzq8vB5W+MoMg1IWMIU2FUcdDw= X-Received: by 2002:a05:6902:90e:b0:669:5bfb:9877 with SMTP id bu14-20020a056902090e00b006695bfb9877mr13346915ybb.323.1656646187678; Thu, 30 Jun 2022 20:29:47 -0700 (PDT) MIME-Version: 1.0 References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> <87r136aze3.fsf@athena.silentflame.com> In-Reply-To: <87r136aze3.fsf@athena.silentflame.com> From: Zachary Kanfer Date: Thu, 30 Jun 2022 23:29:36 -0400 Message-ID: Subject: Re: bug#56311: [PATCH] new function: delete-visited-file To: Sean Whitton Content-Type: multipart/alternative; boundary="0000000000008904d405e2b5ff98" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56311 Cc: Lars Ingebrigtsen , Eli Zaretskii , 56311@debbugs.gnu.org, Visuwesh 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 (-) --0000000000008904d405e2b5ff98 Content-Type: text/plain; charset="UTF-8" It's interesting to see commentary about how one shouldn't want to kill buffers. There is a lot of functionality revolving around killing buffers. > ...each time I see suggestions for features to kill unused buffers or > see people who are worried about such buffers, I raise a brow: in > Emacs, we generally don't care about that (because it does no harm to > have unused buffers)... I use desktop-mode. So I currently have 267 buffers open in my Emacs. Perhaps you might think I'm "doing it wrong", but I find that the more buffers I have open, the longer it takes to find a given buffer. The more open buffers I have open, the greater the chance I'll accidently switch to the wrong one. Sometimes I know that I want a file to go away -- why keep the buffer around? > And since deleting the visited file is currently very easy, as Eli > pointed out: > > > M-x delete-file RET M-n RET > > I don't think this would be a command that people would use a lot. Personally, I never want to delete a file and keep the buffer around. So I have replaced *all* my usages of `delete-file` with this new one. There are many ways to work with Emacs -- many workflows I don't know why this one is considered wrong. On Thu, Jun 30, 2022 at 12:29 PM Sean Whitton wrote: > Hello, > > On Thu 30 Jun 2022 at 12:27pm +02, Lars Ingebrigtsen wrote: > > > And since deleting the visited file is currently very easy, as Eli > > pointed out: > > > > M-x delete-file RET M-n RET > > There's also C-x C-j D. > > > I don't think this would be a command that people would use a lot. > > They shouldn't be using it a lot, and I agree that it probably shouldn't > be added, but it does seem worth noting that a lot of users have > something like this in their init, and use it a lot. I did until today, > and used it almost daily. (After reading this thread, I've replaced it > with something calling bury-buffer.) It's also to be found in Spacemacs > and Doom Emacs. > > -- > Sean Whitton > --0000000000008904d405e2b5ff98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's interesting to see commentary about how one shoul= dn't want to kill buffers. There is a lot of functionality revolving ar= ound killing buffers.

> ...each time I see suggestions for featur= es to kill unused buffers or
> see people who are worried about such = buffers, I raise a brow: in
> Emacs, we generally don't care abou= t that (because it does no harm to
> have unused buffers)...

I= use desktop-mode. So I currently have 267 buffers open in my Emacs. Perhap= s you might think I'm "doing it wrong", but I find that the m= ore buffers I have open, the longer it takes to find a given buffer. The mo= re open buffers I have open, the greater the chance I'll accidently swi= tch to the wrong one. Sometimes I know that I want a file to go away -- why= keep the buffer around?

> And since deleting the visited file is= currently very easy, as Eli
> pointed out:
>
> >=C2= =A0 M-x delete-file RET M-n RET
>
> I don't think this woul= d be a command that people would use a lot.

Personally, I never want= to delete a file and keep the buffer around. So I have replaced *all* my u= sages of `delete-file` with this new one.

There are many ways to wor= k with Emacs -- many workflows I don't know why this one is considered = wrong.

On Thu, Jun 30, 2022 at 12:29 PM Sean Whitton <spwhitton@spwhitton.name> wrote:
Hello,

On Thu 30 Jun 2022 at 12:27pm +02, Lars Ingebrigtsen wrote:

> And since deleting the visited file is currently very easy, as Eli
> pointed out:
>
>=C2=A0 =C2=A0M-x delete-file RET M-n RET

There's also C-x C-j D.

> I don't think this would be a command that people would use a lot.=

They shouldn't be using it a lot, and I agree that it probably shouldn&= #39;t
be added, but it does seem worth noting that a lot of users have
something like this in their init, and use it a lot.=C2=A0 I did until toda= y,
and used it almost daily.=C2=A0 (After reading this thread, I've replac= ed it
with something calling bury-buffer.)=C2=A0 It's also to be found in Spa= cemacs
and Doom Emacs.

--
Sean Whitton
--0000000000008904d405e2b5ff98-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 01 01:58:01 2022 Received: (at 56311) by debbugs.gnu.org; 1 Jul 2022 05:58:01 +0000 Received: from localhost ([127.0.0.1]:36117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o79fF-0005bB-HF for submit@debbugs.gnu.org; Fri, 01 Jul 2022 01:58:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o79fA-0005aw-FB for 56311@debbugs.gnu.org; Fri, 01 Jul 2022 01:57:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42940) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o79f3-0003FS-79; Fri, 01 Jul 2022 01:57:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=n5RIsFOqbsPrsDpzkYsdNkL7TkdGO/T34dMvJPIh7KE=; b=ZV3LllOgwnIB L/VQWA2zPgmT/iuRVc674pO9wA3wbu7yvqT3RTcugwxTExZgS9A+CL1ie5B2d3mD2ETKOMa5g7M2l zO5jeVKZYr02E0/K82m1xNt325JwEV5Vm/LUzggJSshDWVi5bYokTuHDpAomgP3LpVqFcbnHfJd2T TpwEBT3rKWwVlFNPWbOjxRh5IdphG0z5ynoDF1i2gkGEqab6pNNYjheSSR/dzrYiFttQz71K0X8mw BcnJh/P5QQLB78sKmuc8NjhIPsW/8FbNX1TCChfM46CoudJJlDpFhLOu0Ao3/OT7+b1xLVWTdoMFt Cyev1rhUFwwkegHHrbb0Eg==; Received: from [87.69.77.57] (port=3234 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o79f1-00037L-Ri; Fri, 01 Jul 2022 01:57:48 -0400 Date: Fri, 01 Jul 2022 08:57:58 +0300 Message-Id: <831qv5fk7t.fsf@gnu.org> From: Eli Zaretskii To: Zachary Kanfer In-Reply-To: (message from Zachary Kanfer on Thu, 30 Jun 2022 23:29:36 -0400) Subject: Re: bug#56311: [PATCH] new function: delete-visited-file References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> <87r136aze3.fsf@athena.silentflame.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56311 Cc: larsi@gnus.org, visuweshm@gmail.com, 56311@debbugs.gnu.org, spwhitton@spwhitton.name X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zachary Kanfer > Date: Thu, 30 Jun 2022 23:29:36 -0400 > Cc: Lars Ingebrigtsen , Visuwesh , Eli Zaretskii , > 56311@debbugs.gnu.org > > It's interesting to see commentary about how one shouldn't want to kill buffers. There is a lot of functionality > revolving around killing buffers. Examples of such functionality? I'm not sure I understand what you have in mind here. > > ...each time I see suggestions for features to kill unused buffers or > > see people who are worried about such buffers, I raise a brow: in > > Emacs, we generally don't care about that (because it does no harm to > > have unused buffers)... > > I use desktop-mode. So I currently have 267 buffers open in my Emacs. Perhaps you might think I'm "doing > it wrong", Why would I think so? In the session in which I'm writing this, I have 287 buffers. Having around 300 buffers in my sessions is quite normal, and I don't consider such numbers excessive. > I find that the more buffers I have open, the longer it takes to > find a given buffer. "Find" in what way? Please tell more about the problems you have in sessions with many buffers, because I'm not aware of any significant problems. > The more open > buffers I have open, the greater the chance I'll accidently switch > to the wrong one. Again, please tell more details. How does the number of buffers contribute to the chance of selecting a wrong one? For that matter, which commands do you use to switch between buffers? > > And since deleting the visited file is currently very easy, as Eli > > pointed out: > > > > > M-x delete-file RET M-n RET > > > > I don't think this would be a command that people would use a lot. > > Personally, I never want to delete a file and keep the buffer around. So I have replaced *all* my usages of > `delete-file` with this new one. That's fine: Emacs is great because it lets you do that to fit your personal needs. No one here is saying that it's wrong for you to do that; the discussion is whether doing so is TRT for many/most Emacs users (which could have different workflows). > There are many ways to work with Emacs -- many workflows I don't know why this one is considered > wrong. Sure. But there's no reason for Emacs to support all of the OOTB. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 03 01:07:05 2022 Received: (at 56311) by debbugs.gnu.org; 3 Jul 2022 05:07:05 +0000 Received: from localhost ([127.0.0.1]:43134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7rp0-0008Ie-6f for submit@debbugs.gnu.org; Sun, 03 Jul 2022 01:07:05 -0400 Received: from mail-yb1-f169.google.com ([209.85.219.169]:42547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7rov-0008Hf-AK for 56311@debbugs.gnu.org; Sun, 03 Jul 2022 01:07:00 -0400 Received: by mail-yb1-f169.google.com with SMTP id g4so11154664ybg.9 for <56311@debbugs.gnu.org>; Sat, 02 Jul 2022 22:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5kDvqcnuyseJCV8azh8P1Nq1bp3aaMg/pohE5v0v1Uk=; b=qeQXpDvAnDKKu0viZN6ZDwwRUSzgTe9tz6LpGLVXabuW0u4m6csGiC8i/7pNbSUrnj VUvKWw2ioOlarwF2aZAsLIAVmdWgO8Z2fbd81qfBgT8fiLmftVI17l50nK0PBE7K8b5g gu9oVDntu05zwRFyTjUXW+oR21XJO5KseOfLYHr+FC316G/fZRBFJf4MdEwpqElB6yC3 jkdclx7+uzKlB1k87APsO9ohU/sJoBBOcmShy9gePmmWwEMoJErBoWB1ST3hu6iPnt0A zG8qHraKxEk4mZMW3+r0Y+g09ePaVB7uVGjd+GBqy74ZUwljo+apaGdIl02DTuh2o8CG +kdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5kDvqcnuyseJCV8azh8P1Nq1bp3aaMg/pohE5v0v1Uk=; b=WHoFDvEytUg2KhdnxwqjiFEP2biKQ3hbzW8GXGYY5TUvDdXUxVWQ5WA0waihDiaRS5 dJxkLoVrdU5RiU9OAQFvhTHoI2woLlZIXl0UEbjVsoq2r2GZ0DTOJj8AVxiMspBY5qu7 RgqV2xyl6J6AWkXwtzgQpc9ajHtcxhi+nxOeXP3cAe/73W7RjIMM+XMyaRuzcbZM9IMf T/3GCW5FOxqJmB+FsYnh3Vf0AX6sZlykVetxyS6ZZBhMI7LWzkxbiBydnQF10j/PB+9U lAdUw1ppccC37I5OXdtsuMpWj2X4vBjcE1Ri24iWTqeRsZbJ3xeOHzViPuiKQcsNu7qL tDJg== X-Gm-Message-State: AJIora96Cwk7K55rd5GUnDIlExuMk86+EjAEMk7PgiSyy1kvRfWWgkKv 3Bvl3Sw48GBp7hvTDRoLwwo2HM1AaeugnBVffz0= X-Google-Smtp-Source: AGRyM1sV6cgKOCiUY5QkOfwGwcX8y1sagf+eeSQe3HgWlDZ7p9r1cPPhzEhREO3DxGqeHneufDCZtRFbcYciA9Ai7yQ= X-Received: by 2002:a05:6902:90e:b0:669:5bfb:9877 with SMTP id bu14-20020a056902090e00b006695bfb9877mr24367154ybb.323.1656824811623; Sat, 02 Jul 2022 22:06:51 -0700 (PDT) MIME-Version: 1.0 References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> <87r136aze3.fsf@athena.silentflame.com> <831qv5fk7t.fsf@gnu.org> In-Reply-To: <831qv5fk7t.fsf@gnu.org> From: Zachary Kanfer Date: Sun, 3 Jul 2022 01:06:40 -0400 Message-ID: Subject: Re: bug#56311: [PATCH] new function: delete-visited-file To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000005a172905e2df96e9" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 56311 Cc: Lars Ingebrigtsen , Visuwesh , 56311@debbugs.gnu.org, Sean Whitton 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 (-) --0000000000005a172905e2df96e9 Content-Type: text/plain; charset="UTF-8" > > It's interesting to see commentary about how one shouldn't want to kill buffers. There is a lot of functionality > > revolving around killing buffers. > > Examples of such functionality? I'm not sure I understand what you > have in mind here. I mean functions like kill-buffer, eww-buffer-kill,ido-kill-buffer, project-kill-buffers, gnus-kill-buffer. There are many functions that assist killing buffers. > > I find that the more buffers I have open, the longer it takes to > > find a given buffer. > > "Find" in what way? Please tell more about the problems you have in > sessions with many buffers, because I'm not aware of any significant > problems. When trying to switch to a buffer, the more buffers in the list, the more work needs to be done to find the single buffer I do want. > > The more open > > buffers I have open, the greater the chance I'll accidently switch > > to the wrong one. > > Again, please tell more details. How does the number of buffers > contribute to the chance of selecting a wrong one? Say I delete a file, and kill the buffer. Then there is zero chance I'll ever open that buffer accidentally. If I delete a file, and don't kill the buffer, that buffer is there to be accidentally opened. > For that matter, > which commands do you use to switch between buffers? I'm using switch-to-buffer, using selectrum to display and winnow the buffers. > > > And since deleting the visited file is currently very easy, as Eli > > > pointed out: > > > > > > > M-x delete-file RET M-n RET > > > > > > I don't think this would be a command that people would use a lot. > > > > Personally, I never want to delete a file and keep the buffer around. So I have replaced *all* my usages of > > `delete-file` with this new one. > > That's fine: Emacs is great because it lets you do that to fit your > personal needs. No one here is saying that it's wrong for you to do > that In this thread, there are messages like "..we generally don't care about that (because it does no harm to have unused buffers)...", an argument to not close the buffer (because it allowed them to resurrect mistakenly deleted files), and "They shouldn't be using [this command] a lot...". > the discussion is whether doing so is TRT for many/most Emacs > users (which could have different workflows). How would we know if proposed functionality *would* be used by enough users? What is a threshhold for enough users to add a function? On Fri, Jul 1, 2022 at 1:57 AM Eli Zaretskii wrote: > > From: Zachary Kanfer > > Date: Thu, 30 Jun 2022 23:29:36 -0400 > > Cc: Lars Ingebrigtsen , Visuwesh , > Eli Zaretskii , > > 56311@debbugs.gnu.org > > > > It's interesting to see commentary about how one shouldn't want to kill > buffers. There is a lot of functionality > > revolving around killing buffers. > > Examples of such functionality? I'm not sure I understand what you > have in mind here. > > > > ...each time I see suggestions for features to kill unused buffers or > > > see people who are worried about such buffers, I raise a brow: in > > > Emacs, we generally don't care about that (because it does no harm to > > > have unused buffers)... > > > > I use desktop-mode. So I currently have 267 buffers open in my Emacs. > Perhaps you might think I'm "doing > > it wrong", > > Why would I think so? In the session in which I'm writing this, I > have 287 buffers. Having around 300 buffers in my sessions is quite > normal, and I don't consider such numbers excessive. > > > I find that the more buffers I have open, the longer it takes to > > find a given buffer. > > "Find" in what way? Please tell more about the problems you have in > sessions with many buffers, because I'm not aware of any significant > problems. > > > The more open > > buffers I have open, the greater the chance I'll accidently switch > > to the wrong one. > > Again, please tell more details. How does the number of buffers > contribute to the chance of selecting a wrong one? For that matter, > which commands do you use to switch between buffers? > > > > And since deleting the visited file is currently very easy, as Eli > > > pointed out: > > > > > > > M-x delete-file RET M-n RET > > > > > > I don't think this would be a command that people would use a lot. > > > > Personally, I never want to delete a file and keep the buffer around. So > I have replaced *all* my usages of > > `delete-file` with this new one. > > That's fine: Emacs is great because it lets you do that to fit your > personal needs. No one here is saying that it's wrong for you to do > that; the discussion is whether doing so is TRT for many/most Emacs > users (which could have different workflows). > > > There are many ways to work with Emacs -- many workflows I don't know > why this one is considered > > wrong. > > Sure. But there's no reason for Emacs to support all of the OOTB. > --0000000000005a172905e2df96e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > It's interesting to see commentary about how= one shouldn't want to kill buffers. There is a lot of functionality> > revolving around killing buffers.
>
> Examples of su= ch functionality?=C2=A0 I'm not sure I understand what you
> have= in mind here.

I mean functions like kill-buffer, eww-buffer-kill,id= o-kill-buffer, project-kill-buffers, gnus-kill-buffer. There are many funct= ions that assist killing buffers.

> > I find that the more buf= fers I have open, the longer it takes to
> > find a given buffer.<= br>>
> "Find" in what way?=C2=A0 Please tell more about = the problems you have in
> sessions with many buffers, because I'= m not aware of any significant
> problems.

When trying to swit= ch to a buffer, the more buffers in the list, the more work needs to be don= e to find the single buffer I do want.

> > The more open
&g= t; > buffers I have open, the greater the chance I'll accidently swi= tch
> > to the wrong one.
>
> Again, please tell more = details.=C2=A0 How does the number of buffers
> contribute to the cha= nce of selecting a wrong one?

Say I delete a file, and kill the buff= er. Then there is zero chance I'll ever open that buffer accidentally. = If I delete a file, and don't kill the buffer, that buffer is there to = be accidentally opened.

> For that matter,
> which commands= do you use to switch between buffers?

I'm using switch-to-buffe= r, using selectrum to display and winnow the buffers.

> > >= And since deleting the visited file is currently very easy, as Eli
>= > > pointed out:
> > >
> > > >=C2=A0 M-x = delete-file RET M-n RET
> > >
> > > I don't thi= nk this would be a command that people would use a lot.
> >
>= ; > Personally, I never want to delete a file and keep the buffer around= . So I have replaced *all* my usages of
> > `delete-file` with thi= s new one.
>
> That's fine: Emacs is great because it lets = you do that to fit your
> personal needs.=C2=A0 No one here is saying= that it's wrong for you to do
> that

In this thread, ther= e are messages like "..we generally don't care about that (because= it does no harm to have unused buffers)...", an argument to not close= the buffer (because it allowed them to resurrect mistakenly deleted files)= , and "They shouldn't be using [this command] a lot...".
<= br>> the discussion is whether doing so is TRT for many/most Emacs
&g= t; users (which could have different workflows).

How would we know i= f proposed functionality *would* be used by enough users? What is a threshh= old for enough users to add a function?


On Fri, Jul 1, 2022 at 1:57 = AM Eli Zaretskii <eliz@gnu.org> w= rote:
> From:= Zachary Kanfer <= zkanfer@gmail.com>
> Date: Thu, 30 Jun 2022 23:29:36 -0400
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Visuwesh <visuweshm@gmail.com>, Eli Zaretskii <<= a href=3D"mailto:eliz@gnu.org" target=3D"_blank">eliz@gnu.org>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A056311@debbugs.gnu.org
>
> It's interesting to see commentary about how one shouldn't wan= t to kill buffers. There is a lot of functionality
> revolving around killing buffers.

Examples of such functionality?=C2=A0 I'm not sure I understand what yo= u
have in mind here.

> > ...each time I see suggestions for features to kill unused buffer= s or
> > see people who are worried about such buffers, I raise a brow: in=
> > Emacs, we generally don't care about that (because it does no= harm to
> > have unused buffers)...
>
> I use desktop-mode. So I currently have 267 buffers open in my Emacs. = Perhaps you might think I'm "doing
> it wrong",

Why would I think so?=C2=A0 In the session in which I'm writing this, I=
have 287 buffers.=C2=A0 Having around 300 buffers in my sessions is quite normal, and I don't consider such numbers excessive.

> I find that the more buffers I have open, the longer it takes to
> find a given buffer.

"Find" in what way?=C2=A0 Please tell more about the problems you= have in
sessions with many buffers, because I'm not aware of any significant problems.

> The more open
> buffers I have open, the greater the chance I'll accidently switch=
> to the wrong one.

Again, please tell more details.=C2=A0 How does the number of buffers
contribute to the chance of selecting a wrong one?=C2=A0 For that matter, which commands do you use to switch between buffers?

> > And since deleting the visited file is currently very easy, as El= i
> > pointed out:
> >
> > >=C2=A0 M-x delete-file RET M-n RET
> >
> > I don't think this would be a command that people would use a= lot.
>
> Personally, I never want to delete a file and keep the buffer around. = So I have replaced *all* my usages of
> `delete-file` with this new one.

That's fine: Emacs is great because it lets you do that to fit your
personal needs.=C2=A0 No one here is saying that it's wrong for you to = do
that; the discussion is whether doing so is TRT for many/most Emacs
users (which could have different workflows).

> There are many ways to work with Emacs -- many workflows I don't k= now why this one is considered
> wrong.

Sure.=C2=A0 But there's no reason for Emacs to support all of the OOTB.=
--0000000000005a172905e2df96e9-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 03 02:04:53 2022 Received: (at 56311) by debbugs.gnu.org; 3 Jul 2022 06:04:53 +0000 Received: from localhost ([127.0.0.1]:43150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7siy-0001qn-RC for submit@debbugs.gnu.org; Sun, 03 Jul 2022 02:04:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o7siw-0001qZ-Mw for 56311@debbugs.gnu.org; Sun, 03 Jul 2022 02:04:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33232) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7sir-0003WR-7T; Sun, 03 Jul 2022 02:04:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Jozq5/5OqqO4SM9uI6wI4+Nf/TiOkezw3VqUANig9MA=; b=Qz4UUfaaD/zu sYNRWtnCrOOvAtIpA+4DE5b9lqhvxf8JL8sUHGPLN7rFSZgerpqoWnXMN7MSkYZeCUxrda8+3ULTt zWXnp0jWFpaucR1v/jsrFtJm+2S8LOiaHhtxO4deMPZcy6oDfcZV6wuWRbl8FtFOlyck/pNJJQ0B1 0O2U9OE3N2Pk5CUXcg+5LK+5Bhyy7HgP+rYtxDBdypHbvO3GQX9vo4wV25u7ycsZENkn41r+4FKfW sDaO1wZw/OEV2iBqMBmii5CeRjXKIhEkgZOAE8g6fc1FmAKmxYzYMDgS6McKxDmoNEtDbHfS7XntK gIVnXYpAEwIalaOs2GbkZg==; Received: from [87.69.77.57] (port=1072 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7siq-0000L5-Ko; Sun, 03 Jul 2022 02:04:45 -0400 Date: Sun, 03 Jul 2022 09:04:31 +0300 Message-Id: <83zghqag0g.fsf@gnu.org> From: Eli Zaretskii To: Zachary Kanfer In-Reply-To: (message from Zachary Kanfer on Sun, 3 Jul 2022 01:06:40 -0400) Subject: Re: bug#56311: [PATCH] new function: delete-visited-file References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> <87r136aze3.fsf@athena.silentflame.com> <831qv5fk7t.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56311 Cc: larsi@gnus.org, visuweshm@gmail.com, 56311@debbugs.gnu.org, spwhitton@spwhitton.name X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Zachary Kanfer > Date: Sun, 3 Jul 2022 01:06:40 -0400 > Cc: Sean Whitton , Lars Ingebrigtsen , > Visuwesh , 56311@debbugs.gnu.org > > > > It's interesting to see commentary about how one shouldn't want to kill > buffers. There is a lot of functionality > > > revolving around killing buffers. > > > > Examples of such functionality? I'm not sure I understand what you > > have in mind here. > > I mean functions like kill-buffer, eww-buffer-kill,ido-kill-buffer, > project-kill-buffers, gnus-kill-buffer. There are many functions that > assist killing buffers. OK, and what is the relevance of that to the issue at hand? > > > I find that the more buffers I have open, the longer it takes to > > > find a given buffer. > > > > "Find" in what way? Please tell more about the problems you have in > > sessions with many buffers, because I'm not aware of any significant > > problems. > > When trying to switch to a buffer, the more buffers in the list, the more > work needs to be done to find the single buffer I do want. We have several features to make this easier. There's completion on buffer names, there's the "Buffers" menu on the menu bar, there are "C-x C-b" and electric-buffer-list -- and that's only in vanilla Emacs. > > > Personally, I never want to delete a file and keep the buffer around. > So I have replaced *all* my usages of > > > `delete-file` with this new one. > > > > That's fine: Emacs is great because it lets you do that to fit your > > personal needs. No one here is saying that it's wrong for you to do > > that > > In this thread, there are messages like "..we generally don't care about > that (because it does no harm to have unused buffers)...", an argument to > not close the buffer (because it allowed them to resurrect mistakenly > deleted files), and "They shouldn't be using [this command] a lot...". Note the "in general" part. This doesn't contradict your own personal needs, if they are special ones. > > the discussion is whether doing so is TRT for many/most Emacs > > users (which could have different workflows). > > How would we know if proposed functionality *would* be used by enough > users? What is a threshhold for enough users to add a function? We usually judge that by the number of people who request a feature. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 07:12:14 2022 Received: (at 56311) by debbugs.gnu.org; 2 Aug 2022 11:12:14 +0000 Received: from localhost ([127.0.0.1]:42574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpos-0002Cl-ED for submit@debbugs.gnu.org; Tue, 02 Aug 2022 07:12:14 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpop-0002CV-Lv for 56311@debbugs.gnu.org; Tue, 02 Aug 2022 07:12:12 -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:Date:References: In-Reply-To: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=EY9bf8Ua8W7Gtp3Az6MOyjmdMb0YVkVpSNUHFsd0LGc=; b=MYpBnZ+LZ8ni14aouYXSGgp07W K9STQ6en+rC+WS/iYFWLIG7BNhIcEIcIPAjzyB4oWMTCm9FDDIg46urwSQ/GMrcFnWAVxW6FwThSp oFk/Gh7EnmRPvYWq2qu9t2xfgW7i2DhL+b6ObFV3efUtk2xKzcQmqDaS9q9YgPidAaPU=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oIpoh-0007oj-63; Tue, 02 Aug 2022 13:12:05 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#56311: [PATCH] new function: delete-visited-file In-Reply-To: <83zghqag0g.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 Jul 2022 09:04:31 +0300") References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> <87r136aze3.fsf@athena.silentflame.com> <831qv5fk7t.fsf@gnu.org> <83zghqag0g.fsf@gnu.org> X-Now-Playing: The Bug's _In Blue_: "Destroy Me" Date: Tue, 02 Aug 2022 13:12:02 +0200 Message-ID: <874jyuyk59.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.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 discussion is whether doing so is TRT for many/most Emacs >> > users (which could have different workflows). >> >> How would we know if proposed functionality *would* be used by enough >> use [...] 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: 56311 Cc: spwhitton@spwhitton.name, Zachary Kanfer , 56311@debbugs.gnu.org, visuweshm@gmail.com 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 (---) Eli Zaretskii writes: >> > the discussion is whether doing so is TRT for many/most Emacs >> > users (which could have different workflows). >> >> How would we know if proposed functionality *would* be used by enough >> users? What is a threshhold for enough users to add a function? > > We usually judge that by the number of people who request a feature. I think the conclusion here was that there wasn't much enthusiasm for this new function, so I'm closing this bug report. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 07:12:16 2022 Received: (at control) by debbugs.gnu.org; 2 Aug 2022 11:12:17 +0000 Received: from localhost ([127.0.0.1]:42577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpou-0002D2-NM for submit@debbugs.gnu.org; Tue, 02 Aug 2022 07:12:16 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpot-0002Cc-RI for control@debbugs.gnu.org; Tue, 02 Aug 2022 07:12:16 -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=97vHqBkfTtjGIEE0P9zEQUh4Gmxo2Op94d9BrrlNmy4=; b=ZBO2jUl9l+ads2FE7i6UTIr1Cu d4tNXLaeyhLrl4qVcGgLwq7EJc1hu1i5CJYVKBO/7sM0+xdfcnpE04WqKFN6BCOophEwG/MBAjQ+E UTV4txX7NXaY7zuR/utx0WsULJQRxTFk8nKn0XNdoJjnwZWvYA3CgEF/8/CJ5lltTTIY=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oIpom-0007ou-Bk for control@debbugs.gnu.org; Tue, 02 Aug 2022 13:12:10 +0200 Date: Tue, 02 Aug 2022 13:12:07 +0200 Message-Id: <8735eeyk54.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #56311 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 56311 wontfix close 56311 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 (---) tags 56311 wontfix close 56311 quit From unknown Sat Jun 21 03:21:21 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 30 Aug 2022 11:24:03 +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