[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kill-matching-buffers without confirmation

From: Kaushal Modi
Subject: Re: kill-matching-buffers without confirmation
Date: Tue, 23 May 2017 12:51:30 +0000

On Mon, May 22, 2017 at 6:21 PM Drew Adams <address@hidden> wrote:
The suggestions to wrap `kill-matching-buffers' with `cl-letf' or `flet'
are overkill - misguided, IMHO.

Using cl-letf is one of the valid ways. I wouldn't call it an overkill. It instead precisely does what the OP needed without have to rewrite the whole function in the user's config.
You are defining _your own_ command. Just define it directly.  The code to
do that is trivial.  For one thing, you can just copy the existing code of
`kill-matching-buffers' and substitute `kill-buffer' for `kill-buffer-ask'.

That's another way of implementing the solution; neither way is functionally wrong. It just depends on the user preference. In this case it happens that the kill-matching-buffers is a short function. But even then, using cl-letf ends in a shorter solution than re-writing the whole function.

Here are few advantages of not re-writing core functions in user configs:

- User might forget what exactly were they trying to redefine in that function in their config (if they didn't comment it well). Inherently it's not evident what the user is trying to override in their config... One has to diff with the version in the core to understand the differences. This applies to the user as well as to anyone else looking at the user's config if shared publicly.
- As I mentioned above, re-writing is not as concise.
- If the core version of the function changes/gets improved/bug fixed, there are chances that the cl-letf'ed function will still work. If you rewrote the function in your config, you might keep on using the older version of the function forever without knowing of improvements in the source. 
  And if the cl-letf'd function breaks, that's good too as at least that you prompt you to fix things locally to match the core.
- By using facilities like cl-letf, (and along the same lines, advices), you can surgically modify only the stuff you need. It's less cognitive load to have the code tell what exactly is being changed.

I don't think that Emacs needs either (1) a new, non-confirming command for
this or (2) a variable to inhibit confirmation by `kill-matching-buffers'.

Option (1) never came up.. it was only suggested that the user define a new command in their config. 

I don't even think that Emacs needs commands `kill-matching-buffers' and
`kill-some-buffers' at all, for that matter.

There have been multiple occasions when something in Emacs core I thought being of not use to me suddenly becomes useful. Even I don't find kill-matching-buffers useful (at the moment), but the OP does. I just use ibuffer to batch kill stuff if needed by matching not just buffer names, but even paths, project root dirs, modes, etc.

Kaushal Modi

reply via email to

[Prev in Thread] Current Thread [Next in Thread]