From: Drew Adams <drew.adams@oracle.com>
To: "R. Diez" <rdiezmail-emacs@yahoo.de>
Cc: emacs-devel@gnu.org
Subject: RE: kill-matching-buffers without confirmation
Date: Tue, 23 May 2017 13:34:59 -0700 (PDT) [thread overview]
Message-ID: <b9c70238-76a5-4994-8e9e-7aea8bb7d34b@default> (raw)
In-Reply-To: <1873780790.87721.1495520903689@mail.yahoo.com>
> > 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.
next prev parent reply other threads:[~2017-05-23 20:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <537757403.6158992.1495470490914.ref@mail.yahoo.com>
2017-05-22 16:28 ` kill-matching-buffers without confirmation R. Diez
2017-05-22 18:21 ` Kaushal Modi
2017-05-22 18:34 ` Clément Pit-Claudel
2017-05-22 18:42 ` Kaushal Modi
2017-05-22 18:45 ` Clément Pit-Claudel
2017-05-22 19:00 ` Kaushal Modi
2017-05-22 19:13 ` Clément Pit-Claudel
2017-05-22 19:20 ` Kaushal Modi
2017-05-22 19:34 ` Stefan Monnier
2017-05-22 22:21 ` Drew Adams
2017-05-23 5:28 ` Yuri Khan
2017-05-23 6:28 ` R. Diez
2017-05-23 20:34 ` Drew Adams [this message]
2017-05-23 12:51 ` Kaushal Modi
2017-05-23 13:03 ` Stefan Monnier
2017-05-23 13:18 ` Kaushal Modi
2017-05-24 1:50 ` zhanghj
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9c70238-76a5-4994-8e9e-7aea8bb7d34b@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=rdiezmail-emacs@yahoo.de \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.