Re: kill-matching-buffers without confirmation

[Kaushal Modi <kaushal.modi@gmail.com>]

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

On Mon, May 22, 2017 at 6:21 PM Drew Adams <drew.adams@oracle.com> 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

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