From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: kill-matching-buffers without confirmation Date: Tue, 23 May 2017 12:51:30 +0000 Message-ID: References: <537757403.6158992.1495470490914.ref@mail.yahoo.com> <537757403.6158992.1495470490914@mail.yahoo.com> <6e11051e-1a41-426b-97be-de1d70480c34@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11401ae2022225055030734e" X-Trace: blaine.gmane.org 1495543951 11339 195.159.176.226 (23 May 2017 12:52:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 May 2017 12:52:31 +0000 (UTC) To: Drew Adams , "R. Diez" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 23 14:52:24 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dD9IV-0002gS-Nr for ged-emacs-devel@m.gmane.org; Tue, 23 May 2017 14:52:23 +0200 Original-Received: from localhost ([::1]:48821 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dD9IY-0005bB-8x for ged-emacs-devel@m.gmane.org; Tue, 23 May 2017 08:52:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dD9Ht-0005b4-4N for emacs-devel@gnu.org; Tue, 23 May 2017 08:51:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dD9Hr-0003pL-Mn for emacs-devel@gnu.org; Tue, 23 May 2017 08:51:45 -0400 Original-Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:34393) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dD9Hr-0003ox-9Y for emacs-devel@gnu.org; Tue, 23 May 2017 08:51:43 -0400 Original-Received: by mail-lf0-x234.google.com with SMTP id 99so47738598lfu.1 for ; Tue, 23 May 2017 05:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=v0IL9by4H39UQnTP4UsQtQtQBXxXyOA9xIiVsGtyG7M=; b=jhwQGcCaj7XPAaKGmzVsxamu+UPYLXzObD/w1yzG3lDIO043jNhiops0JHIm843MfT E79j6ouYz6q3yZVmDVZpcIrDYrr3+IXm876rvkMQePkyFbxHwxG02UBUc2eJyUC0kJn/ ljZmY46MK4yi6s6A5i/ww3JSKlBCji/0RtzHe4efGFiO7UMaxj5drbB01UGsxHoUjSqr kAuGCB1mheVa/H0nPmtEfbdhSNY5JQsMsdi0icCaNfvpd5hLD2T3IhTzl+Z8mOQq2vUD Rg2HVv3pOPCvbDbFv7C23CR+4qyxXkpT5KYR75u6gs11mkQO/KtAjNsTLFgi0EAEw/I3 7xrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=v0IL9by4H39UQnTP4UsQtQtQBXxXyOA9xIiVsGtyG7M=; b=lNvd2O2XF3Bj8OjIRbnwgs7WVjgcmeCQX0EZHWKa9pMLv5Qmw2sqzIGWsfLzM43pQb iZpbS+c3bb7iWPzPNL0BMcLIzQzGW6vN3Hr3RjYVdEtMVBBJXSvoTyedcUA7gtcdNJ+I IHG2/UeQvMf/yHrY+kVXNbw4hL1pGk74mW+3lP6TUPaQnWUWceisSEvnawKs1gd9sUhM bs1YiLPd1pq/NiTAQAtlmFEgXQBshtfY76bHcsKzfW4Peioxbb9GMq46yc2TGVnwj8aG KptrmOmS7woYu24bwPNKYm5Ea/SPqhBUQTSWBqoCkp0zpx9UqVMq/O54ooaI335BImn3 uf2g== X-Gm-Message-State: AODbwcCf3ueLhdGSEtpXxZPVsT2WVC1ACpzqqfuxGxjVgeHmF9AmNGqw L6KzvkljHtkrt+qboFqs0BTieIa8nw== X-Received: by 10.25.26.81 with SMTP id a78mr7658390lfa.5.1495543901721; Tue, 23 May 2017 05:51:41 -0700 (PDT) In-Reply-To: <6e11051e-1a41-426b-97be-de1d70480c34@default> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215127 Archived-At: --001a11401ae2022225055030734e Content-Type: text/plain; charset="UTF-8" On Mon, May 22, 2017 at 6:21 PM Drew Adams 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 --001a11401ae2022225055030734e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 22= , 2017 at 6:21 PM Drew Adams <d= rew.adams@oracle.com> wrote:
The suggestions to wrap `kill-matching-buffers' with `cl-letf' or = `flet'
are overkill - misguided, IMHO.

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

That's another way of = implementing the solution; neither way is functionally wrong. It just depen= ds on the user preference. In this case it happens that the kill-matching-b= uffers 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:
<= div>
- User might forget what exactly were they trying to red= efine 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 th= eir config... One has to diff with the version in the core to understand th= e differences. This applies to the user as well as to anyone else looking a= t the user's config if shared publicly.
- As I mentioned abov= e, re-writing is not as concise.
- If the core version of the fun= ction changes/gets improved/bug fixed, there are chances that the cl-letf&#= 39;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.=C2=A0
=C2=A0 And if the cl= -letf'd function breaks, that's good too as at least that you promp= t you to fix things locally to match the core.
- By using facilit= ies like cl-letf, (and along the same lines, advices), you can surgically m= odify only the stuff you need. It's less cognitive load to have the cod= e 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= 9;.

Option (1) never came up.. it was o= nly suggested that the user define a new command in their config.=C2=A0

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

<= /div>
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 f= ind kill-matching-buffers useful (at the moment), but the OP does. I just u= se ibuffer to batch kill stuff if needed by matching not just buffer names,= but even paths, project root dirs, modes, etc.
--

Kaushal Modi

--001a11401ae2022225055030734e--