unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Zachary Kanfer <zkanfer@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	Visuwesh <visuweshm@gmail.com>,
	56311@debbugs.gnu.org, Sean Whitton <spwhitton@spwhitton.name>
Subject: bug#56311: [PATCH] new function: delete-visited-file
Date: Sun, 3 Jul 2022 01:06:40 -0400	[thread overview]
Message-ID: <CAFXT+RMrdxbzJE0Jeji6ZJ5uNoijH3BhciHwh9LE7U5fVfQSVw@mail.gmail.com> (raw)
In-Reply-To: <831qv5fk7t.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4960 bytes --]

> > 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 <eliz@gnu.org> wrote:

> > 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 <eliz@gnu.org>,
> >       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.
>

[-- Attachment #2: Type: text/html, Size: 6330 bytes --]

  reply	other threads:[~2022-07-03  5:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30  4:26 bug#56311: [PATCH] new function: delete-visited-file Zachary Kanfer
2022-06-30  5:30 ` Eli Zaretskii
2022-06-30  5:49   ` Sean Whitton
2022-06-30  5:56     ` Eli Zaretskii
2022-06-30  6:20   ` Visuwesh
2022-06-30 10:27     ` Lars Ingebrigtsen
2022-06-30 16:29       ` Sean Whitton
2022-07-01  3:29         ` Zachary Kanfer
2022-07-01  5:57           ` Eli Zaretskii
2022-07-03  5:06             ` Zachary Kanfer [this message]
2022-07-03  6:04               ` Eli Zaretskii
2022-08-02 11:12                 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFXT+RMrdxbzJE0Jeji6ZJ5uNoijH3BhciHwh9LE7U5fVfQSVw@mail.gmail.com \
    --to=zkanfer@gmail.com \
    --cc=56311@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    --cc=spwhitton@spwhitton.name \
    --cc=visuweshm@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).