From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zachary Kanfer Newsgroups: gmane.emacs.bugs Subject: bug#56311: [PATCH] new function: delete-visited-file Date: Sun, 3 Jul 2022 01:06:40 -0400 Message-ID: References: <83k08y67ml.fsf@gnu.org> <87wncyr7st.fsf@gmail.com> <87wncybg4z.fsf@gnus.org> <87r136aze3.fsf@athena.silentflame.com> <831qv5fk7t.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005a172905e2df96e9" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4657"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Visuwesh , 56311@debbugs.gnu.org, Sean Whitton To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 03 07:08:14 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o7rqA-00016S-1Y for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Jul 2022 07:08:14 +0200 Original-Received: from localhost ([::1]:34438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7rq8-0001hd-Jn for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 Jul 2022 01:08:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56716) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7rpy-0001hV-AQ for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2022 01:08:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49237) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o7rpy-0001cE-1p for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2022 01:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o7rpx-0008Px-Oi for bug-gnu-emacs@gnu.org; Sun, 03 Jul 2022 01:08:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Zachary Kanfer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 03 Jul 2022 05:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56311 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo patch Original-Received: via spool by 56311-submit@debbugs.gnu.org id=B56311.165682482532028 (code B ref 56311); Sun, 03 Jul 2022 05:08:01 +0000 Original-Received: (at 56311) by debbugs.gnu.org; 3 Jul 2022 05:07:05 +0000 Original-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 Original-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 Original-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) In-Reply-To: <831qv5fk7t.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:235962 Archived-At: --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--