kill-matching-buffers without confirmation

kill-matching-buffers without confirmation

[R. Diez]

Hallo all:

Could someone please add a clean way for 'kill-matching-buffers' to not ask for confirmation? Apparently, I am not the only once that has hit this nag:

https://stackoverflow.com/questions/10929915/how-do-i-answer-y-automatically-kill-matching-buffers-asks-if-i-should-kill-a-m

I am tired of overriding 'kill-buffer-ask' with flet as suggested there, and then seeing this warning:

Warning (bytecomp): ‘flet’ is an obsolete macro (as of 24.3); use either ‘cl-flet’ or ‘cl-letf’.

And then remembering that cl-flet does not work, and it gets complicated with Lisp macros, dynamic something, etc. I am no Elisp expert.


I am sending this e-mail to this mailing list because that function lives in files.el, which states at the top:

;; Maintainer: emacs-devel@gnu.org
;; Package: emacs


Please copy me on the answer, as I am not subscribed to the list.

Regards,
  rdiez

Re: kill-matching-buffers without confirmation

[Kaushal Modi]

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

On Mon, May 22, 2017 at 2:11 PM R. Diez <rdiezmail-emacs@yahoo.de> wrote:

>
> Please copy me on the answer, as I am not subscribed to the list.
>

For future, all help questions can go to help-gnu-emacs@gnu.org

To answer your question, here is one way:

    (defun kill-matching-buffers-just-do-it ()
      "Kill buffers whose names match REGEXP, without asking."
      (interactive)
      (cl-letf (((symbol-function 'kill-buffer-ask) #'kill-buffer))
        (call-interactively #'kill-matching-buffers)))

-- 

Kaushal Modi

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

Re: kill-matching-buffers without confirmation

[Clément Pit-Claudel]

On 2017-05-22 14:21, Kaushal Modi wrote:
> For future, all help questions can go to help-gnu-emacs@gnu.org <mailto:help-gnu-emacs@gnu.org>

The OP looked like a feature request actually; wouldn't bug-gnu-emacs be more appropriate?
(Your workaround works, but the OP was about a clean way to do that, and a new defun + an flet is relatively heavy)

Clément.

Re: kill-matching-buffers without confirmation

[Kaushal Modi]

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

On Mon, May 22, 2017 at 2:34 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> The OP looked like a feature request actually; wouldn't bug-gnu-emacs be
> more appropriate?
>

Yes, definitely.


> (Your workaround works, but the OP was about a clean way to do that, and a
> new defun + an flet is relatively heavy)
>

I found the cl-left approach very concise. But yes, if this is a feature
request, then may be add another optional argument?
-- 

Kaushal Modi

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

Re: kill-matching-buffers without confirmation

[Clément Pit-Claudel]

On 2017-05-22 14:42, Kaushal Modi wrote:
>> (Your workaround works, but the OP was about a clean way to do that, and a new defun + an flet is relatively heavy)
> I found the cl-left approach very concise. But yes, if this is a feature request, then may be add another optional argument?

Or a defcustom, since it seems that the usual approach is to override the behavior unconditionally.

Re: kill-matching-buffers without confirmation

[Kaushal Modi]

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

On Mon, May 22, 2017 at 2:45 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> Or a defcustom, since it seems that the usual approach is to override the
> behavior unconditionally.
>

A defcustom seems too risky for this. A user can unknowingly copy that var
from somewhere and then end up killing modified buffers without
confirmation.

Add a new defun that just sets the new optional arg to non-nil value is
less risky as the user would then be knowingly calling the risky variant.
The default kill-matching-buffers will still remain safe.

What do you think?
-- 

Kaushal Modi

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

Re: kill-matching-buffers without confirmation

[Clément Pit-Claudel]

On 2017-05-22 15:00, Kaushal Modi wrote:
> A defcustom seems too risky for this. A user can unknowingly copy that var from somewhere and then end up killing modified buffers without confirmation.

I don't think we've applied such a standard before: we have multiple other variables that disable confirmation prompts, like confirm-nonexistent-file-or-buffer, confirm-kill-processes or kill-buffer-query-functions.

> Add a new defun that just sets the new optional arg to non-nil value is less risky as the user would then be knowingly calling the risky variant.

Isn't there a similar risk of a user unknowingly copying code that rebinds the default binding to the risky variant?

Cheers,
Clément.

Re: kill-matching-buffers without confirmation

[Kaushal Modi]

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

On Mon, May 22, 2017 at 3:13 PM Clément Pit-Claudel <cpitclaudel@gmail.com>
wrote:

> Isn't there a similar risk of a user unknowingly copying code that rebinds
> the default binding to the risky variant?
>

I cannot argue with that :)
-- 

Kaushal Modi

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

Re: kill-matching-buffers without confirmation

[Stefan Monnier]

>> A defcustom seems too risky for this. A user can unknowingly copy that var
>> from somewhere and then end up killing modified buffers
>> without confirmation.
> I don't think we've applied such a standard before: we have multiple other
> variables that disable confirmation prompts, like
> confirm-nonexistent-file-or-buffer, confirm-kill-processes or
> kill-buffer-query-functions.

Killing a modified buffer means throwing away data without any way to
recover it, so it's kind of "almost always dangerous".  In contrast
confirm-nonexistent-file-or-buffer is never dangerous,
confirm-kill-processes can be dangerous but it very much depends, and
kill-buffer-query-functions (which *is* dangerous as well) is not
a defcustom.


        Stefan

RE: kill-matching-buffers without confirmation

[Drew Adams]

> Could someone please add a clean way for 'kill-matching-buffers' to not ask
> for confirmation?...
> 
> I am tired of overriding 'kill-buffer-ask' with flet as suggested there,
> and then seeing this warning:
> 
>   Warning (bytecomp): ‘flet’ is an obsolete macro (as of 24.3); use either
>   ‘cl-flet’ or ‘cl-letf’.
> 
> And then remembering that cl-flet does not work, and it gets complicated
> with Lisp macros, dynamic something, etc. I am no Elisp expert.

The suggestions to wrap `kill-matching-buffers' with `cl-letf' or `flet'
are overkill - misguided, IMHO.

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'.

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'.

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

----

[What Emacs should offer instead is a way for `C-x k' to act (by hitting
a key) on *each* completion of your input.  And ways to match buffer names
better, possibly choosing how on the fly: substring, regexp, fuzzy.

And a way to progressively narrow the set of matches.  And a way to act on
specific matches but not all.  And a way to act on non-matches.  And a way
to filter buffer-name matches to keep or remove those for modified buffers.

(In Icicles, you use `C-x k', type a regexp, complete, and hit `C-!'
to kill all of the matches.  To filter out the modified buffers, just
use `C-x * -' before hitting `C-!'.  So that's `C-x k TAB C-x * -'.
And you can use `C-M-down' to see info about each buffer, including
whether it is modified.  And the same keys work for other commands
that use buffer-name completion, e.g., `C-x 4 b'.)]

Re: kill-matching-buffers without confirmation

[Yuri Khan]

On Tue, May 23, 2017 at 5:21 AM, Drew Adams <drew.adams@oracle.com> wrote:

> I don't even think that Emacs needs commands `kill-matching-buffers' and
> `kill-some-buffers' at all, for that matter.
>
> [What Emacs should offer instead is a way for `C-x k' to act (by hitting
> a key) on *each* completion of your input.  And ways to match buffer names
> better, possibly choosing how on the fly: substring, regexp, fuzzy.

Another UI for the same use case is:

* Open up a buffer list (e.g. ibuffer).
* Mark buffers by regexp (‘% n’ in ibuffer).
* Inspect the list to ensure it’s what you expect. Possibly mark or unmark some.
* Kill marked buffers.

If any of those are unsaved, a prompt could offer the “yes for all”
choice, like ! does in query-replace.

Re: kill-matching-buffers without confirmation

[R. Diez]

> You are defining _your own_ command. Just define it directly.
> The code to do that is trivial.

I think you are misguided here. You seem to believe that Emacs users are confident Elisp programmers.

This is the source code of kill-matching-buffers:



(defun kill-matching-buffers (regexp &optional internal-too)

"Kill buffers whose name matches the specified REGEXP.
The optional second argument indicates whether to kill internal buffers too."

(interactive "sKill buffers matching this regular expression: \nP")

(dolist (buffer (buffer-list))
(let ((name (buffer-name buffer)))
(when (and name (not (string-equal name ""))
(or internal-too (/= (aref name 0) ?\s))
(string-match regexp name))
(kill-buffer-ask buffer)))))



It is not clear to me what internal buffers are, or why some of them could have an empty name. I cannot see a reason why I, as a regular user, should care.



> For one thing, you can just copy the existing code of
>`kill-matching-buffers' and substitute `kill-buffer' for `kill-buffer-ask'.

This is really bad advice. If the next version of Emacs changes the implementation of that routine, my copy will miss those changes.


My use case is not actually interactive. I just want to close the buffers that ediff automatically creates from its exit hook, but I have other scenarios where other things automatically load buffers that I no longer want. I do that kind of clean-up in a hook, no interaction required.


> [What Emacs should offer instead is a way for `C-x k' to act (by hitting

No, this is not what I need. I do not want interactive selection or fuzzy matches. I know exactly what pattern to use. What you are describing is a separate enhancement for interactive usage.


[Obligatory rant follows]

I am just asking for a little convenience function. It is almost what kill-matching-buffers does, just without hard-coded confirmation.

This is a recurrent pattern with Emacs. Everything is so complicated, and there is so much discussion.

There are other open-source projects which do not advice their users to create a bug themselves after posting a request, or which do not tell them to write their own code for each little thing. If a small improvement helps the regular user in his daily life, they just do it! The mere existence of the Stack Overflow question and the first replies here with cl-letf  etc. should make it obvious that such a convenience function/flag would help.


Regards,
  rdiez

RE: kill-matching-buffers without confirmation

[Drew Adams]

> > You are defining _your own_ command. Just define it directly.
> > The code to do that is trivial.
> 
> I think you are misguided here. You seem to believe that Emacs
> users are confident Elisp programmers.

No, not really.  But if you're defining your own command then you
need to know _something_ about Elisp.

And if you are using `cl-letf' or `flet' then I'd suggest that you
should maybe be at least as familiar with Elisp as what you'll need
to be to understand the code of `kill-matching-buffers' and to
substitute `kill-buffer' for `kill-buffer-ask' there.

I think that the code for `kill-matching-buffers' is a lot easier for
a non-Lisper to understand than is the use of `cl-letf' or `flet',
which are macros that define and apply functions, using generalized
variables.

Just one opinion, of course.

> This is the source code of kill-matching-buffers:
> 
> (defun kill-matching-buffers (regexp &optional internal-too)
> (interactive "sKill buffers matching this regular expression: \nP")
>   (dolist (buffer (buffer-list))
>     (let ((name (buffer-name buffer)))
>       (when (and name (not (string-equal name ""))
>                  (or internal-too (/= (aref name 0) ?\s))
>                  (string-match regexp name))
>         (kill-buffer-ask buffer)))))

`C-h f kill-buffer-ask' tells you: "Kill BUFFER if confirmed."
`C-h f kill-buffer' says: "Kill the buffer specified by BUFFER-OR-NAME."

Without looking at the code defining them, you might guess that
a difference is that the former prompts for confirmation and the
latter does not.

Not that I suggest you rely only on doc strings and not look at
the code, but a reasonable guess is that you can replace
`kill-buffer-ask' by `kill-buffer', to kill a buffer without
being asked for confirmation.

Anyway, I didn't expect you to necessarily come up with this
on your own: I offered it to you, as one possible solution.

> It is not clear to me what internal buffers are, or why some of them could
> have an empty name. I cannot see a reason why I, as a regular user, should
> care.

You are the user of `kill-matching-buffers', not I.  It is
the doc of that command that speaks of internal buffers.
If you don't understand what they are, and if you don't
care, then you needn't be concerned with them.

The doc says: "The optional second argument indicates whether
to kill internal buffers too."  That's bad doc (IMO).  How
does that arg "indicate whether"?  And what does "optional
second argument" mean to an interactive user?

That doc should say: (1) by default, internal buffers are
ignored and (2) with a prefix argument they are not ignored.
It can add that non-interactively, non-nil optional arg
INTERNAL-TOO means they are not ignored.

You will need to consult the more general Emacs doc if you
really want to know what an internal buffer is.  But you can
just ignore what it is and not use a prefix arg.

In any case, you need not care to know about internal buffers
with the solution I offered any more than you would need to
care about it with the solution of using `cl-letf' or `flet'.
The latter just calls `kill-matching-buffers, so you are back
to reading its doc string and wondering what on Earth an
internal buffer is.

> > For one thing, you can just copy the existing code of
> > `kill-matching-buffers' and substitute `kill-buffer' for
> > `kill-buffer-ask'.
> 
> This is really bad advice. If the next version of Emacs changes the
> implementation of that routine, my copy will miss those changes.

Don't follow it, if you think it's really bad advice.

> My use case is not actually interactive. I just want to close the buffers
> that ediff automatically creates from its exit hook, but I have other
> scenarios where other things automatically load buffers that I no longer
> want. I do that kind of clean-up in a hook, no interaction required.

Clearly you are a confident Elisp programmer, in spite of what you
said earlier. ;-)

In that case, it is hard to believe that you would have difficulty
following the code of `kill-matching-buffers'.

> > [What Emacs should offer instead is a way for `C-x k' to act
> 
> No, this is not what I need. I do not want interactive selection or fuzzy
> matches. I know exactly what pattern to use. What you are describing is a
> separate enhancement for interactive usage.

Yes, well, your initial message did not say that you were not
looking for interactive killing of buffers.  In fact, you pointed
to an SO question that explicitly tries to define a command to do
it (interactively).  And the answers to that question did the same.
That was clearly all about interactive killing of buffers without
being prompted to confirm.

And you'll note that at least one person (not I) did not understand
that you were making an enhancement request and not asking for help
to come up with your own command.  You were not clear, I think.

Please forgive me for trying to help without being a mind-reader.
I'll try not to let it happen again.

> [Obligatory rant follows]
> 
> I am just asking for a little convenience function. It is almost
> what kill-matching-buffers does, just without hard-coded confirmation.
> 
> This is a recurrent pattern with Emacs. Everything is so complicated,
> and there is so much discussion.

Things are generally much less complicated if you make clear from
the outset just what you are asking.  People spend time trying to
help you, and you berate them for not guessing correctly what you
had in mind.  Next time, things might be a lot less complicated. ;-)

> There are other open-source projects which do not advice their
> users to create a bug themselves after posting a request,

If someone suggested somewhere that you do `M-x report-emacs-bug'
to submit your enhancement request, that's a good response.  That's
the recommended way to submit enhancement requests.  You can
instead send your request to this list, but in any case,
your request will likely get more traction if it is clear.

> or which do not tell them
> to write their own code for each little thing. If a small improvement helps
> the regular user in his daily life, they just do it! The mere existence of
> the Stack Overflow question and the first replies here with cl-letf  etc.
> should make it obvious that such a convenience function/flag would help.

I happen to agree 100% that it is fine to request "little things",
as well as big things, from Emacs Dev.  And that little improvements
can sometimes make a great difference for users.

I don't think anyone told you that your suggestion is unwelcome.

Personally, I don't think that `kill-matching-buffers' and
`kill-some-buffers' are very useful.  By that I mean that they,
or similar, could be more useful.  One of the ways `k-m-b' could
be more useful is precisely what you're looking for: let the
prompting be optional.

And yes, I'm more interested in having Emacs provide ways for
users to do such filtering and acting on things like buffers
interactively.  That's missing.  Providing a function like
`kill-matching-buffers' for non-interactive use is not so
important, to me.  Just one opinion.

Re: kill-matching-buffers without confirmation

[Kaushal Modi]

[-- 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 --]

Re: kill-matching-buffers without confirmation

[Stefan Monnier]

>> 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.

No, not "precisely".  It does more than you want.  E.g. it will also
affect other threads which could be running at the same time, or any
other piece of code that might run during this dynamic scope (e.g. while
debugging this code).

It's good we can use such a workaround when there's no other solution,
but let's not design things in a way that requires the use of such hacks.


        Stefan

Re: kill-matching-buffers without confirmation

[Kaushal Modi]

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

On Tue, May 23, 2017 at 9:03 AM Stefan Monnier <monnier@iro.umontreal.ca>
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.
>
> No, not "precisely".  It does more than you want.  E.g. it will also
> affect other threads which could be running at the same time, or any
> other piece of code that might run during this dynamic scope (e.g. while
> debugging this code).
>

TIL. Thanks.


> It's good we can use such a workaround when there's no other solution,
> but let's not design things in a way that requires the use of such hacks.


I agree.

The OP hasn't weighed in yet. But if it needs to be fixed, OP should file a
bug report requesting that.

Else, he can simply redefine the function in the config as Drew suggested.
-- 

Kaushal Modi

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

Re: kill-matching-buffers without confirmation

[zhanghj]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> On Tue, May 23, 2017 at 9:03 AM Stefan Monnier <monnier@iro.umontreal.ca>
> 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.
>>
>> No, not "precisely".  It does more than you want.  E.g. it will also
>> affect other threads which could be running at the same time, or any
>> other piece of code that might run during this dynamic scope (e.g. while
>> debugging this code).
>>
>
> TIL. Thanks.
>
>
>> It's good we can use such a workaround when there's no other solution,
>> but let's not design things in a way that requires the use of such hacks.
>
>
> I agree.
>
> The OP hasn't weighed in yet. But if it needs to be fixed, OP should file a
> bug report requesting that.
>
> Else, he can simply redefine the function in the config as Drew suggested.

What about a command like this:

(defun kill-matching-buffers (donot-ask)
(interactive "P")
(...))