From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers Date: Wed, 10 Jul 2024 13:42:40 -0400 Message-ID: References: <86ed81o5oc.fsf@gnu.org> <8634ohnwpz.fsf@gnu.org> <86zfqpm9ur.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30433"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 72019@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 10 19:43:16 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sRbLX-0007f7-B9 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Jul 2024 19:43:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRbLI-0005JL-T9; Wed, 10 Jul 2024 13:43:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sRbLG-0005Hi-Nm for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2024 13:42:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sRbLE-0008GW-8h for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2024 13:42:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sRbLK-00044U-AA for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2024 13:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Jul 2024 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72019 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 72019-submit@debbugs.gnu.org id=B72019.172063337615638 (code B ref 72019); Wed, 10 Jul 2024 17:43:02 +0000 Original-Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:42:56 +0000 Original-Received: from localhost ([127.0.0.1]:57092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbLD-00044A-LB for submit@debbugs.gnu.org; Wed, 10 Jul 2024 13:42:56 -0400 Original-Received: from mxout6.mail.janestreet.com ([64.215.233.21]:49329) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sRbLA-00043v-3s for 72019@debbugs.gnu.org; Wed, 10 Jul 2024 13:42:53 -0400 In-Reply-To: <86zfqpm9ur.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Jul 2024 20:32:12 +0300") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1720633360; bh=7FSyN3Kegqmi0k76zw35kNFAZQ4CfypOBDskG53M9/E=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=y0oPwNs5mm6EmphmwJVRExDWue12Y4Jw8gweAjat5Hr2qRBVzqkXUz9zmPMhE+Yec JfjV8y0aGQyP2XNNaDDSdydCm5e0Js0Qe5kLLXdoo9RT39SgvHR0fWIRZEpliomOz+ mOLB6RQ8hl3uzQhGmBVNAyilWeo1eb9b5estNfudprtvDGZezbDnNifClWFPSePyV2 KMfIZkj/Q/HHv9TqiTV0XWJo/ke1pm02/twiqT4LnNFLomCDfCM+WlJNOkPEn1tX3h F4gxpqEGoveiP6jr8fzI9KEn1LkV8T8uk/25f4W7Y7oj6QVAwRApyDC5jSVQJe+j3K OtT4SLfTudvHQ== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288692 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: 72019@debbugs.gnu.org >> Date: Wed, 10 Jul 2024 11:47:48 -0400 >>=20 >> Eli Zaretskii writes: >>=20 >> >> From: Spencer Baugh >> >> Date: Wed, 10 Jul 2024 09:27:06 -0400 >> >> Cc: 72019@debbugs.gnu.org >> >>=20 >> >> On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii wr= ote: >> >>=20 >> >> > From: Spencer Baugh >> >> > Date: Tue, 09 Jul 2024 14:31:11 -0400 >> >> >=20 >> >> > Previously, project-kill-buffers always called (project-current t)= . A >> >> > Lisp program could change what project project-kill-buffers operat= ed >> >> > on by binding project-current-directory-override. However, in some >> >> > edge cases (for example, if the project was deleted between lookin= g it >> >> > up and calling project-kill-buffers) this might fail to detect a >> >> > project, and so (project-current t) would prompt the user. >> >> >=20 >> >> > To avoid this, accept the project to kill buffers for as an argume= nt. >> >>=20 >> >> That sounds like sweeping some minor bug under the carpet, or worse. >> >> Why is it a good idea to silently second-guess what is TRT in these >> >> marginal cases? Up front, I'd say asking the user is a safer bet. >> >>=20 >> >> Suppose if some Lisp program runs (project-current t) to select a pro= ject to operate on, then does some >> >> things, then runs project-kill-buffers. The p-k-b call should never = prompt for a project again - it's intended to >> >> operate on the project that was already selected. If the project tha= t was already selected has disappeared, an >> >> error is better than a confusing second prompt which might lead to th= e user selecting another different >> >> project and killing all the buffers in that project. If the Lisp pro= gram wants to catch that error, it can. >> > >> > In my book, prompting the user with the like of >> > >> > Project FOO disappeared, continue killing its buffers? >> > >> > is better than silently doing the (potentially) wrong thing. IOW, >> > when something that isn't supposed to happen did happen, let the human >> > figure out the mess. Relying on project.el to signal an error is >> > better, but might not be the best idea, either, because the error >> > message is likely to be confusing and/or non-specific. >>=20 >> Yes, that's all true. However, this is a minor edge case, which so far >> I've only observed happen once, and then it was only due to a user's bad >> configuration. I'd rather just signal an error for now (by avoiding the >> call to (project-current t)), which the current patch will do, since >> that improves on the situation without requiring us to invest more >> effort on something very rare. > > If we want to signal an error, let's signal an error, but with an > explicit error message explaining the problem. Doing that by adding > an argument sounds risky, since it doesn't target this specific > situation, and so installing on the release branch is not necessarily > justified. Are you okay with diagnosing this specific situation and > signaling an error explicitly in the code? I don't need this to be on the release branch. I'd prefer to add the argument and just keep this on master.