GNU logs - #72019, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 09 Jul 2024 18:32:01 +0000
Resent-Message-ID: <handler.72019.B.17205498889903 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 72019 <at> debbugs.gnu.org
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Tue, 09 Jul 2024 14:31:11 -0400
Message-ID: <ierfrsiifio.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN;
 helo=mxout5.mail.janestreet.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

--=-=-=
Content-Type: text/plain

Tags: patch


Previously, project-kill-buffers always called (project-current t).  A
Lisp program could change what project project-kill-buffers operated
on by binding project-current-directory-override.  However, in some
edge cases (for example, if the project was deleted between looking it
up and calling project-kill-buffers) this might fail to detect a
project, and so (project-current t) would prompt the user.

To avoid this, accept the project to kill buffers for as an argument.

* lisp/progmodes/project.el (project-kill-buffers): Take project as an
optional argument.


In GNU Emacs 29.2.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2024-06-01 built on
 igm-qws-u22796a
Repository revision: fcef787a846f0c51f7443dfab6af6e18b476b166
Repository branch: emacs-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure --with-x-toolkit=lucid --without-gpm --without-gconf
 --without-selinux --without-imagemagick --with-modules --with-gif=no
 --with-cairo --with-rsvg --without-compress-install
 --with-native-compilation=aot --with-tree-sitter
 PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'


--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
 filename=0001-Add-project-argument-to-project-kill-buffers.patch

From 5fdd9735148a5b009c0a2a4339c88bf8ab177f37 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Tue, 9 Jul 2024 14:30:27 -0400
Subject: [PATCH] Add project argument to project-kill-buffers

Previously, project-kill-buffers always called (project-current t).  A
Lisp program could change what project project-kill-buffers operated
on by binding project-current-directory-override.  However, in some
edge cases (for example, if the project was deleted between looking it
up and calling project-kill-buffers) this might fail to detect a
project, and so (project-current t) would prompt the user.

To avoid this, accept the project to kill buffers for as an argument.

* lisp/progmodes/project.el (project-kill-buffers): Take project as an
optional argument.
---
 lisp/progmodes/project.el | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index b7c1698f50b..3d0f742c51d 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1715,7 +1715,7 @@ project--buffers-to-kill
     bufs))
 
 ;;;###autoload
-(defun project-kill-buffers (&optional no-confirm)
+(defun project-kill-buffers (&optional no-confirm project)
   "Kill the buffers belonging to the current project.
 Two buffers belong to the same project if their project
 instances, as reported by `project-current' in each buffer, are
@@ -1725,9 +1725,11 @@ project-kill-buffers
 NO-CONFIRM is always nil when the command is invoked
 interactively.
 
+If PROJECT is non-nil, kill buffers for that project instead.
+
 Also see the `project-kill-buffers-display-buffer-list' variable."
   (interactive)
-  (let* ((pr (project-current t))
+  (let* ((pr (or project (project-current t)))
          (bufs (project--buffers-to-kill pr))
          (query-user (lambda ()
                        (yes-or-no-p
-- 
2.39.3


--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Spencer Baugh <sbaugh@HIDDEN>
Subject: bug#72019: Acknowledgement ([PATCH] Add project argument to
 project-kill-buffers)
Message-ID: <handler.72019.B.17205498889903.ack <at> debbugs.gnu.org>
References: <ierfrsiifio.fsf@HIDDEN>
X-Gnu-PR-Message: ack 72019
X-Gnu-PR-Package: emacs
X-Gnu-PR-Keywords: patch
Reply-To: 72019 <at> debbugs.gnu.org
Date: Tue, 09 Jul 2024 18:32:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 72019 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
72019: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72019
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 09 Jul 2024 20:01:02 +0000
Resent-Message-ID: <handler.72019.B72019.172055520518997 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Spencer Baugh <sbaugh@HIDDEN>, 72019 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
Feedback-ID: i0e71465a:Fastmail
Message-ID: <8e654f47-04bd-4089-92c4-dfb49132397c@HIDDEN>
Date: Tue, 9 Jul 2024 22:59:46 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <ierfrsiifio.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <ierfrsiifio.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi!

On 09/07/2024 21:31, Spencer Baugh wrote:
> Tags: patch
> 
> 
> Previously, project-kill-buffers always called (project-current t).  A
> Lisp program could change what project project-kill-buffers operated
> on by binding project-current-directory-override.  However, in some
> edge cases (for example, if the project was deleted between looking it
> up and calling project-kill-buffers) this might fail to detect a
> project, and so (project-current t) would prompt the user.
> 
> To avoid this, accept the project to kill buffers for as an argument.
> 
> * lisp/progmodes/project.el (project-kill-buffers): Take project as an
> optional argument.

LGTM.

Eli, is this okay for emacs-30?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 11:20:02 +0000
Resent-Message-ID: <handler.72019.B72019.172061039116619 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Date: Wed, 10 Jul 2024 14:19:31 +0300
Message-Id: <86ed81o5oc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <ierfrsiifio.fsf@HIDDEN> (message from Spencer Baugh on
 Tue, 09 Jul 2024 14:31:11 -0400)
References: <ierfrsiifio.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Spencer Baugh <sbaugh@HIDDEN>
> Date: Tue, 09 Jul 2024 14:31:11 -0400
> 
> Previously, project-kill-buffers always called (project-current t).  A
> Lisp program could change what project project-kill-buffers operated
> on by binding project-current-directory-override.  However, in some
> edge cases (for example, if the project was deleted between looking it
> up and calling project-kill-buffers) this might fail to detect a
> project, and so (project-current t) would prompt the user.
> 
> To avoid this, accept the project to kill buffers for as an argument.

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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 11:44:02 +0000
Resent-Message-ID: <handler.72019.B72019.172061183229887 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: sbaugh@HIDDEN, 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172061183229887
          (code B ref 72019); Wed, 10 Jul 2024 11:44:02 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 11:43:52 +0000
Received: from localhost ([127.0.0.1]:55035 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRVjk-0007lz-BU
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 07:43:52 -0400
Received: from eggs.gnu.org ([209.51.188.92]:50624)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRVji-0007ll-9E
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 07:43:50 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRVjV-0000yz-Tx; Wed, 10 Jul 2024 07:43:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=atrF94FztqgR094xeHGPslItGb2zDj3hZ89M/GN1HeQ=; b=MofHPK5wkCRO
 2RoFxlIsHkyAijI06mVQGGCDCZtCbQO8v7UnMKH9Rwrciwg0vsyJJkLMeCgobcArlAGuU//PtXWj5
 CqDFZAgn2bSBcXktQfsWGm477T2CXo8RFq22Zkejawy295tW2ReyZLe+2YQm5018aJr2ogbbC/egH
 H9amlY4hCkPFb+eQq3iZ5sYub/npc1Dcse38dJo8pUiXyeGapIiKIlLTfBPi+W2hDTjDO/7quqd31
 wiqoLV26x/sqh54gU0P0SBNriYo2W34NyDP9KhG3dv5kLH1WP0cw07QWTlx4BR3BWnbRQ9FhFC8TI
 u1wUW5bsZZGcLt28LYHqeQ==;
Date: Wed, 10 Jul 2024 14:43:19 +0300
Message-Id: <86a5ipo4ko.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <8e654f47-04bd-4089-92c4-dfb49132397c@HIDDEN> (message from
 Dmitry Gutov on Tue, 9 Jul 2024 22:59:46 +0300)
References: <ierfrsiifio.fsf@HIDDEN>
 <8e654f47-04bd-4089-92c4-dfb49132397c@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 9 Jul 2024 22:59:46 +0300
> From: Dmitry Gutov <dmitry@HIDDEN>
> 
> Hi!
> 
> On 09/07/2024 21:31, Spencer Baugh wrote:
> > Tags: patch
> > 
> > 
> > Previously, project-kill-buffers always called (project-current t).  A
> > Lisp program could change what project project-kill-buffers operated
> > on by binding project-current-directory-override.  However, in some
> > edge cases (for example, if the project was deleted between looking it
> > up and calling project-kill-buffers) this might fail to detect a
> > project, and so (project-current t) would prompt the user.
> > 
> > To avoid this, accept the project to kill buffers for as an argument.
> > 
> > * lisp/progmodes/project.el (project-kill-buffers): Take project as an
> > optional argument.
> 
> LGTM.
> 
> Eli, is this okay for emacs-30?

As I wrote a few minutes ago, I don't think I like this change in
principle, let alone for Emacs 30.  Feel free to point out where I'm
wrong or what am I missing.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 13:28:02 +0000
Resent-Message-ID: <handler.72019.B72019.17206180528531 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.17206180528531
          (code B ref 72019); Wed, 10 Jul 2024 13:28:02 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 13:27:32 +0000
Received: from localhost ([127.0.0.1]:55144 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRXM4-0002DW-0G
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 09:27:32 -0400
Received: from mxout1.mail.janestreet.com ([38.105.200.78]:50045)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sbaugh@HIDDEN>) id 1sRXM0-0002DA-O6
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 09:27:29 -0400
Received: from mail-lf1-f72.google.com ([209.85.167.72])
 by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128)
 (Exim 4.97.1) id 1sRXLp-00000009AvJ-0yTv for 72019 <at> debbugs.gnu.org;
 Wed, 10 Jul 2024 09:27:17 -0400
Received: by mail-lf1-f72.google.com with SMTP id
 2adb3069b0e04-52ebdb0ef28so1698958e87.0
 for <72019 <at> debbugs.gnu.org>; Wed, 10 Jul 2024 06:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=janestreet.com; s=google; t=1720618036; x=1721222836; darn=debbugs.gnu.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=8egLtGg5dmF4VuYJutIPIzfQ69V3eFTR6nrrSr0hyNE=;
 b=wmYNvKm7rBWqnWSvbD9pfG7Vxhk9p8d/sI3Y/U3/ypMS9uQXmcl0ETDV49lNuIHCoW
 gIbrSp9YguOXvLJZRVYTqyIbUO6O6bU49y79prJ7Cbwsive8D6eUf3jjS2g9Rj2oTy4k
 JQX+EVYVmat8HxxG4bZk4CkdaOZQ87XmBHrFg=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
 s=waixah; t=1720618037;
 bh=8egLtGg5dmF4VuYJutIPIzfQ69V3eFTR6nrrSr0hyNE=;
 h=References:In-Reply-To:From:Date:Subject:To:Cc;
 b=tmcErx0j/hVdscsRE++8QfhzGIMV+dwJI+/RMQk/xTDifmkVrHly2xt0s3US0Rv4d
 hj+euP1tdm8Sr1JcW+jpvPMWH5D+t7qU/NZK+gvI6Bgffwk/6cMXhltySgHhhpS/dO
 0P7/NjPxY0wpF/TFDpaPnU4cpMcQHRrkAlHgQv2CcbbtGDc/1fPOCq2avFfNIUVuNl
 5KCIZciNtHJBD6z2ASkY7ggdkHE0Mq7PlGtIsNJeSyZc326LCS+teC4ei5qSlX6FEI
 LgtPL6gUgztJSGN9tnbaZa8bwMXxJUyy6UYD2xWZOJqG4DXqBiwB08+C+mBLZ9UEPM
 gRDbBZ2d4PxPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1720618036; x=1721222836;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=8egLtGg5dmF4VuYJutIPIzfQ69V3eFTR6nrrSr0hyNE=;
 b=JXsfGFq+9AWze9ykK4cTB9H6e4eCyQPKDZx7dAOLiwFQHtxxCVjK9gH5xkq5ZkFR3K
 bm6lywS5AQO0N5qAKKvJC7ma5iic6vxYvhTgDYqjLdZhgiVWHTj+dqQoFLS213G0Jqjt
 IAVaF3wOBJgoMBUCskq/QCN7CyyuUi0VMrMXDLBdSqxC9Wvc/u9HluevY15HGsg5BaZ8
 QT2SFl3JFOZi7nTzM3GZeweNpgCrUS25bUsIIWMw8vHGuuZOaMehKU+zy4eXoL8fukD/
 Hf9Z/8thce6PCmYu4mb+cBrT565Iu5DwSpIFFnJwP3FKvCnzAMMfB2TJVNx1kfJgCCBa
 QwCQ==
X-Gm-Message-State: AOJu0YzVcXpbdUWN8CMfB5BBZSgJWeJ74X3DNrFt2XNOxpEFDKNtyyNN
 p0NFWHkJbIwnU35KA+7j3eIof/iGhp5CnYzoqHK7579fa87NUPyEFuDNRoqR9kg2kpTgnGNO2Oj
 fb8vHs7cNM4Mb5yloA6pb8AXVNXJARZcIImePezA42cxeheQN/bPLpXoqlbTBTgKAkYq7t4P3Wu
 U+tm5OCDZEwhRSHcn3azLjl3C3wQ==
X-Received: by 2002:a05:6512:3f14:b0:52c:df55:e11a with SMTP id
 2adb3069b0e04-52eb9990a43mr4400466e87.9.1720618036252; 
 Wed, 10 Jul 2024 06:27:16 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFNqFZ5726eqdgQRpEXewxgydyNXGzxwr45k0GlNUYn0l3T8ncyV2Pu97AEypIFq+WVRV2+u8KU8bPyULgNlHI=
X-Received: by 2002:a05:6512:3f14:b0:52c:df55:e11a with SMTP id
 2adb3069b0e04-52eb9990a43mr4400452e87.9.1720618035786; Wed, 10 Jul 2024
 06:27:15 -0700 (PDT)
MIME-Version: 1.0
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
In-Reply-To: <86ed81o5oc.fsf@HIDDEN>
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Wed, 10 Jul 2024 09:27:06 -0400
Message-ID: <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000d1532b061ce49a2c"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000d1532b061ce49a2c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Spencer Baugh <sbaugh@HIDDEN>
> > Date: Tue, 09 Jul 2024 14:31:11 -0400
> >
> > Previously, project-kill-buffers always called (project-current t).  A
> > Lisp program could change what project project-kill-buffers operated
> > on by binding project-current-directory-override.  However, in some
> > edge cases (for example, if the project was deleted between looking it
> > up and calling project-kill-buffers) this might fail to detect a
> > project, and so (project-current t) would prompt the user.
> >
> > To avoid this, accept the project to kill buffers for as an argument.
>
> 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.
>

Suppose if some Lisp program runs (project-current t) to select a project
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 that was
already selected has disappeared, an error is better than a confusing
second prompt which might lead to the user selecting another different
project and killing all the buffers in that project.  If the Lisp program
wants to catch that error, it can.

>

--000000000000d1532b061ce49a2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii &l=
t;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">&gt; From: Spencer Baugh &lt;<a href=3D"mailto:s=
baugh@HIDDEN" target=3D"_blank" rel=3D"noreferrer">sbaugh@janestree=
t.com</a>&gt;<br>
&gt; Date: Tue, 09 Jul 2024 14:31:11 -0400<br>
&gt; <br>
&gt; Previously, project-kill-buffers always called (project-current t).=C2=
=A0 A<br>
&gt; Lisp program could change what project project-kill-buffers operated<b=
r>
&gt; on by binding project-current-directory-override.=C2=A0 However, in so=
me<br>
&gt; edge cases (for example, if the project was deleted between looking it=
<br>
&gt; up and calling project-kill-buffers) this might fail to detect a<br>
&gt; project, and so (project-current t) would prompt the user.<br>
&gt; <br>
&gt; To avoid this, accept the project to kill buffers for as an argument.<=
br>
<br>
That sounds like sweeping some minor bug under the carpet, or worse.<br>
Why is it a good idea to silently second-guess what is TRT in these<br>
marginal cases?=C2=A0 Up front, I&#39;d say asking the user is a safer bet.=
<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Suppose if some Lisp program runs (project-current t) to select a project t=
o operate on, then does some things, then runs project-kill-buffers.=C2=A0 =
The p-k-b call should never prompt for a project again - it&#39;s intended =
to operate on the project that was already selected.=C2=A0 If the project t=
hat was already selected has disappeared, an error is better than a confusi=
ng second prompt which might lead to the user selecting another different p=
roject and killing all the buffers in that project.=C2=A0 If the Lisp progr=
am wants to catch that error, it can.</div><div dir=3D"auto"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000d1532b061ce49a2c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 14:34:01 +0000
Resent-Message-ID: <handler.72019.B72019.172062203917292 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172062203917292
          (code B ref 72019); Wed, 10 Jul 2024 14:34:01 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 14:33:59 +0000
Received: from localhost ([127.0.0.1]:56888 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRYOM-0004Up-Fr
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 10:33:59 -0400
Received: from eggs.gnu.org ([209.51.188.92]:57644)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRYO6-0004UG-4w
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 10:33:56 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRYNu-0007Fw-8a; Wed, 10 Jul 2024 10:33:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=mihEuHutWlJMrh0ChnV7MljSC718MF81Jm6Fd0U8p3Y=; b=qPf1aZNERHpk77/E7jGY
 CyHZXwzHUHyV3b4WXzYdrNd0QQxTPzQ6EEKelFggImhkXMyM7NWjwBnFC6RWhcNpvyNbuDzbaVuiq
 fko795bzSI20seGwxIxZQH8zZKaVbQfJmbTbKzp2nFK4h8lZtHsSMYgo1hRfLCkVOhgMCXVRPHC7c
 OmMfUhFbYFMVTQGuv8XIWH7Z2COxENLHXU3yDoJ9XjLu+txZMBERKjVcLuoOO59zEjhBEpohpDZfa
 QjClW3BsTP1LUDu0j4+NvaR+s6s1AV1igtlQaSdSgD7wWtNfZgYhP+PHMpvEYTTGjvk7nfl0/TnR4
 n4zup8akBthsrA==;
Date: Wed, 10 Jul 2024 17:32:56 +0300
Message-Id: <8634ohnwpz.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 (message from Spencer Baugh on Wed, 10 Jul 2024 09:27:06 -0400)
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Spencer Baugh <sbaugh@HIDDEN>
> Date: Wed, 10 Jul 2024 09:27:06 -0400
> Cc: 72019 <at> debbugs.gnu.org
> 
> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@HIDDEN> wrote:
> 
>  > From: Spencer Baugh <sbaugh@HIDDEN>
>  > Date: Tue, 09 Jul 2024 14:31:11 -0400
>  > 
>  > Previously, project-kill-buffers always called (project-current t).  A
>  > Lisp program could change what project project-kill-buffers operated
>  > on by binding project-current-directory-override.  However, in some
>  > edge cases (for example, if the project was deleted between looking it
>  > up and calling project-kill-buffers) this might fail to detect a
>  > project, and so (project-current t) would prompt the user.
>  > 
>  > To avoid this, accept the project to kill buffers for as an argument.
> 
>  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.
> 
> Suppose if some Lisp program runs (project-current t) to select a project 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 that was already selected has disappeared, an
> error is better than a confusing second prompt which might lead to the user selecting another different
> project and killing all the buffers in that project.  If the Lisp program 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 15:49:02 +0000
Resent-Message-ID: <handler.72019.B72019.172062648325311 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172062648325311
          (code B ref 72019); Wed, 10 Jul 2024 15:49:02 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 15:48:03 +0000
Received: from localhost ([127.0.0.1]:56966 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRZY2-0006aB-N6
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 11:48:03 -0400
Received: from mxout6.mail.janestreet.com ([64.215.233.21]:38151)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sbaugh@HIDDEN>) id 1sRZY0-0006Zd-6H
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 11:48:01 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <8634ohnwpz.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 10 Jul
 2024 17:32:56 +0300")
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN>
Date: Wed, 10 Jul 2024 11:47:48 -0400
Message-ID: <iercynli6zf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
 s=waixah; t=1720626468;
 bh=zg6Yq9+20fLQ/oz4EaN83mHMoo8FAuGba4/YLftDWtc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=JqR97ZIUAZBC3o/SBqRhTVed302eWehnx2zwHmeEVydcoe1pMcVEMT+LFBOJS9w4s
 +HLnTZqIB1lvZ5RxPf2YxVcBaCwpp7fj1YFenAzLU2vJJxpCSfgOWE77Yo+5teDnW5
 5J4Sb+NE/LfbkG4nEUYK60VTYioJG5owGOB7U2+cgkOmC5ME45tYPpQuRB4CX1soa+
 F/Ya1QM+GbwBGP1lw6w3sWXH9Q34DP8WIay+QW/QqrkpJnebdG6ZRmjSUY0lFQTa89
 NQnj2j29EkO+JRUtd2mJli8vIV76M/ShdH9QA9A1/1ZUEXlDkMyiFGzZUUUJmHQv67
 fSdaGmG5CDT7Q==
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Date: Wed, 10 Jul 2024 09:27:06 -0400
>> Cc: 72019 <at> debbugs.gnu.org
>>=20
>> On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:
>>=20
>>  > From: Spencer Baugh <sbaugh@HIDDEN>
>>  > 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 operated
>>  > on by binding project-current-directory-override.  However, in some
>>  > edge cases (for example, if the project was deleted between looking 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 argument.
>>=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 projec=
t to operate on, then does some
>> things, then runs project-kill-buffers.  The p-k-b call should never pro=
mpt for a project again - it's intended to
>> operate on the project that was already selected.  If the project that w=
as already selected has disappeared, an
>> error is better than a confusing second prompt which might lead to the u=
ser selecting another different
>> project and killing all the buffers in that project.  If the Lisp progra=
m 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.

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 it keeps happening, I'll send a future patch which further improves
things.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 17:33:02 +0000
Resent-Message-ID: <handler.72019.B72019.172063275314692 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172063275314692
          (code B ref 72019); Wed, 10 Jul 2024 17:33:02 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:32:33 +0000
Received: from localhost ([127.0.0.1]:57076 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRbBB-0003ot-7p
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 13:32:33 -0400
Received: from eggs.gnu.org ([209.51.188.92]:40010)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRbB8-0003of-HN
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 13:32:31 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRbAv-0006gr-0N; Wed, 10 Jul 2024 13:32:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=uoflJqjWSgQp6nRDdaEnQEZhEauPMc8SbL0bzFAHeMo=; b=q/s/pcQAWD4Do8f5uXI/
 yk4F/hyoBe/sqaMxvI7w4HR1H5FVVIe0Ex5DBwKdzK6bdr/O3TpThgftroYSy8kGStYJ0UYM6Ik8m
 u05dtw68931skhewpoLpNVohb7Nz9DfYmAFe+/C1cbMq5g9tP18IWU/Iw3JWXZHBFnUJfT3O4sqcv
 JS+i+ZV6uFC3vnT+FLbswRPePjHEmyU8lIhuOH9bwBj6258FunLvpOiIBP+NoyfyDAY9LK09QNCNs
 chJ7tzNdVRszBbfOcXT2FMGG7eanzR0MRdy7NdcZEnAISzKZCEPrXcNHNaehKhMRaa/PMDumYxTPm
 n9XFeAAU9/OirA==;
Date: Wed, 10 Jul 2024 20:32:12 +0300
Message-Id: <86zfqpm9ur.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <iercynli6zf.fsf@HIDDEN> (message from Spencer Baugh on
 Wed, 10 Jul 2024 11:47:48 -0400)
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Spencer Baugh <sbaugh@HIDDEN>
> Cc: 72019 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2024 11:47:48 -0400
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> From: Spencer Baugh <sbaugh@HIDDEN>
> >> Date: Wed, 10 Jul 2024 09:27:06 -0400
> >> Cc: 72019 <at> debbugs.gnu.org
> >> 
> >> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@HIDDEN> wrote:
> >> 
> >>  > From: Spencer Baugh <sbaugh@HIDDEN>
> >>  > Date: Tue, 09 Jul 2024 14:31:11 -0400
> >>  > 
> >>  > Previously, project-kill-buffers always called (project-current t).  A
> >>  > Lisp program could change what project project-kill-buffers operated
> >>  > on by binding project-current-directory-override.  However, in some
> >>  > edge cases (for example, if the project was deleted between looking it
> >>  > up and calling project-kill-buffers) this might fail to detect a
> >>  > project, and so (project-current t) would prompt the user.
> >>  > 
> >>  > To avoid this, accept the project to kill buffers for as an argument.
> >> 
> >>  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.
> >> 
> >> Suppose if some Lisp program runs (project-current t) to select a project 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 that was already selected has disappeared, an
> >> error is better than a confusing second prompt which might lead to the user selecting another different
> >> project and killing all the buffers in that project.  If the Lisp program 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.
> 
> 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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 17:43:02 +0000
Resent-Message-ID: <handler.72019.B72019.172063337615638 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172063337615638
          (code B ref 72019); Wed, 10 Jul 2024 17:43:02 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:42:56 +0000
Received: from localhost ([127.0.0.1]:57092 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRbLD-00044A-LB
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 13:42:56 -0400
Received: from mxout6.mail.janestreet.com ([64.215.233.21]:49329)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sbaugh@HIDDEN>) id 1sRbLA-00043v-3s
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 13:42:53 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <86zfqpm9ur.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 10 Jul
 2024 20:32:12 +0300")
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
 <86zfqpm9ur.fsf@HIDDEN>
Date: Wed, 10 Jul 2024 13:42:40 -0400
Message-ID: <iera5ipi1nz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Cc: 72019 <at> debbugs.gnu.org
>> Date: Wed, 10 Jul 2024 11:47:48 -0400
>>=20
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>=20
>> >> From: Spencer Baugh <sbaugh@HIDDEN>
>> >> Date: Wed, 10 Jul 2024 09:27:06 -0400
>> >> Cc: 72019 <at> debbugs.gnu.org
>> >>=20
>> >> On Wed, Jul 10, 2024, 7:19=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wr=
ote:
>> >>=20
>> >>  > From: Spencer Baugh <sbaugh@HIDDEN>
>> >>  > 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 17:55:02 +0000
Resent-Message-ID: <handler.72019.B72019.172063409816814 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172063409816814
          (code B ref 72019); Wed, 10 Jul 2024 17:55:02 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 17:54:58 +0000
Received: from localhost ([127.0.0.1]:57108 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRbWs-0004N8-1i
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 13:54:58 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53618)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRbWn-0004Mt-4S
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 13:54:56 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRbWb-0002Ah-35; Wed, 10 Jul 2024 13:54:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=JM5MVLMCYBQHDxf1bLbfclKBCC05LLFLf6L4hH7DAnA=; b=B29PLSLkMEle
 tydEsPzGkpYZf2XnaNUNqNmBSKKwdy2vhaS26aBWo08IMmPRaR12XoRWJHgKwCTUCMo3E7IxVWX4F
 0eOB14BuGKDTAeFOuL60U+b8t4HfgDE6HC1hbpfDzrXMFNy+lDHgmzR3iYLebS8snLFmjb0DYR7il
 OXKdePwROZW2mo/CvMaci3R9xtuTmUp313Tnq3jO2XrRzGTUwYgSJA4AAHNnPc2uAeUAcTbpoHwAj
 Ji410gaL4qtklm/qNubf9XRL5d70DONpB11VRVQLdFKS15RSbjf7wzxt6gzDZfJwH/U2GgPzV+Efm
 tuIkGLbJIuG7PKf4328BrQ==;
Date: Wed, 10 Jul 2024 20:54:37 +0300
Message-Id: <86v81dm8te.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <iera5ipi1nz.fsf@HIDDEN> (message from Spencer Baugh on
 Wed, 10 Jul 2024 13:42:40 -0400)
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
 <86zfqpm9ur.fsf@HIDDEN> <iera5ipi1nz.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Spencer Baugh <sbaugh@HIDDEN>
> Cc: 72019 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2024 13:42:40 -0400
> 
> > 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.

Why do you prefer to add an argument?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 18:31:01 +0000
Resent-Message-ID: <handler.72019.B72019.172063621920578 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172063621920578
          (code B ref 72019); Wed, 10 Jul 2024 18:31:01 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 18:30:19 +0000
Received: from localhost ([127.0.0.1]:57140 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRc54-0005Lp-Tj
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 14:30:19 -0400
Received: from mxout6.mail.janestreet.com ([64.215.233.21]:53505)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <sbaugh@HIDDEN>) id 1sRc51-0005Lb-IL
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 14:30:17 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <86v81dm8te.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 10 Jul
 2024 20:54:37 +0300")
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
 <86zfqpm9ur.fsf@HIDDEN> <iera5ipi1nz.fsf@HIDDEN>
 <86v81dm8te.fsf@HIDDEN>
Date: Wed, 10 Jul 2024 14:30:02 -0400
Message-ID: <ier7cdthzh1.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
 s=waixah; t=1720636202;
 bh=h6PFbcellK3RH/1ecVr7ogrhZjXm/R5bEwArcWpaQPQ=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=yDv8p4SVRgAh0Zpua1KRUVDUY5402xHpWNK2+0jOkWtEDA1WKQrCw8/seCiMzlRgk
 /Fv4Qu7lr2LCawGno5zKHgfMhpGddW6ZYG1HwiZfAEvsalyVrMkxtXrMQ5rsleg/y0
 NznbEq+ads10CrlmoyIfTju7X3NEPgSUjnfk5c4rRY1K1Qz3p3r8vKs6TVh3zKdn0z
 KhJPMptxJHhrZas55acdeptE7itC//sTtv9corqjKyl6mK/Eiy4OK50HLGTuKva+vo
 ZKoZQcXpX285xjESY1Tys9Y3v7X7nkNedkRAOlBGlfr1z/2ds8LNKTP770fN/W2bm4
 J9xjlR3g6b0MQ==
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Cc: 72019 <at> debbugs.gnu.org
>> Date: Wed, 10 Jul 2024 13:42:40 -0400
>> 
>> > 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.
>
> Why do you prefer to add an argument?

Because it is also nicer to explicitly indicate what project the Lisp
program is operating on.  Going through project-current means there are
a number of possible bugs.  Lisp programs should pass in the project
instance; this is preferred for new project.el-using code.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jul 2024 19:01:01 +0000
Resent-Message-ID: <handler.72019.B72019.17206380541929 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.17206380541929
          (code B ref 72019); Wed, 10 Jul 2024 19:01:01 +0000
Received: (at 72019) by debbugs.gnu.org; 10 Jul 2024 19:00:54 +0000
Received: from localhost ([127.0.0.1]:57180 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRcYg-0000V3-2K
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 15:00:54 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52962)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRcYc-0000Up-TY
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 15:00:52 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRcYQ-0005rM-Sl; Wed, 10 Jul 2024 15:00:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=2kBAKzQAdlbkTx99dPgAeOMJ8Linnj7YmukN6qLnEGc=; b=kbT/1qSwly/M
 1R025SKUnQc86sCd0DwHtmOh65X+Di/RCgXjoLpA9UTPglPMnnJc1JfwO7xwmBWuz3pG4FTRsglY3
 RIf6ofNwITAnlRZy+Y5XB5xVkSUGsT7r6BFTum79s+5m3ffSU2UjbnJSK8z3TjYJNQi/LXQjX0mK/
 jAS/GPgLstfh3fdeItvGPPLCSo7U0iwCyCxndm+ivO5ujj7qUam9qIQTBtA963XuKaPD6ToA1eoLK
 EnanXg53m07wbme+8ugv5SMc4hzLbY9DpgP1JMDbsQOWPG1uo5J/P5WTYweU7ZceH+wJubnWfH/EI
 asvZTimZe6MbUb7VCR3fCg==;
Date: Wed, 10 Jul 2024 22:00:33 +0300
Message-Id: <86sewhm5ri.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <ier7cdthzh1.fsf@HIDDEN> (message from Spencer Baugh on
 Wed, 10 Jul 2024 14:30:02 -0400)
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
 <86zfqpm9ur.fsf@HIDDEN> <iera5ipi1nz.fsf@HIDDEN>
 <86v81dm8te.fsf@HIDDEN> <ier7cdthzh1.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Spencer Baugh <sbaugh@HIDDEN>
> Cc: 72019 <at> debbugs.gnu.org
> Date: Wed, 10 Jul 2024 14:30:02 -0400
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> I don't need this to be on the release branch.  I'd prefer to add the
> >> argument and just keep this on master.
> >
> > Why do you prefer to add an argument?
> 
> Because it is also nicer to explicitly indicate what project the Lisp
> program is operating on.  Going through project-current means there are
> a number of possible bugs.  Lisp programs should pass in the project
> instance; this is preferred for new project.el-using code.

If this is the current trend in project.el development, then I have no
objections to it.  I find it a bit surprising that the original
motivation for this was something completely different, though.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 11 Jul 2024 00:12:02 +0000
Resent-Message-ID: <handler.72019.B72019.172065672124874 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172065672124874
          (code B ref 72019); Thu, 11 Jul 2024 00:12:02 +0000
Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 00:12:01 +0000
Received: from localhost ([127.0.0.1]:50552 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRhPk-0006T8-Mh
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 20:12:00 -0400
Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]:45431)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1sRhPg-0006Ss-VI
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 20:11:58 -0400
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 3981F1140424;
 Wed, 10 Jul 2024 20:11:52 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute4.internal (MEProxy); Wed, 10 Jul 2024 20:11:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm1; t=1720656712;
 x=1720743112; bh=pPUVkdjF65xJbB03fGDZuNkvN8rZQMMwTTfs9L+vFqo=; b=
 RUYtlxZtmQBKlF4NEK/aWioPANRCau52QAyBIp2uj1OXeb9vOpPmumDf06OR+jow
 o4cuDwkQydW997a12xpGWFo3X+8Tmd1Oes/okNqO96SkL4Ih32RXSg/yrPpmvUak
 N4Bd2mddQvhPxqpH0xzWDxwaCeBkeQRlAsHggplIWoYetx6Czn8B4ceTMBMSk8ga
 IdtjoPnfcvIUw1RkTs9sEcJfvQojbTkb0hqOf8Djya1Q1Ra2GBVPxgOp1C7bwE63
 VJGZt89hZ6GYugBfuxaPjmy75pDjYAcRLUXxixsuaKaPTUm0xFFP/psVyCFS9+0O
 7OR1VHGHFmjaNUYnXtAx3g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720656712; x=
 1720743112; bh=pPUVkdjF65xJbB03fGDZuNkvN8rZQMMwTTfs9L+vFqo=; b=h
 xLPRrWuebYLY4lWi4uFnCoFMCWRLX7YqGQG7oFGfgGAIXJWT19z9vQY5KYFBVekd
 LjnHDLrGCAG7yDVSprIivMpQMvox8uKh5thWQI+QKZCyd4GZdGAI8+TYB4q5W9gq
 d6acY+OuQcA+1QmpUlVU09K7pJwjre/K1+eAdSW7Symq7dp6xb2SYe39bymW3Gee
 0LByFmtn4NFDz3VJr4Sfli28gbGctLkdL2xdaTqbTMHNpCBbROL46F1CuF4lSVjm
 wGZQQT3ar6plgmwci7w81KNx91oe8ynm2g5NgDuQLD/qSv0YBZ1aA1mwXbQjdPSH
 TUMC3l06CSesCkeSY6hsQ==
X-ME-Sender: <xms:RiOPZg4Yw5_zCWyCx9o2JatdH_GqazxhZBISA2dw9t5QqzvUYcL02g>
 <xme:RiOPZh7ui-a0Sg7DPf_o-XnXLeBU09jW4Ut8jFccj6dVKs0H2PjhlLt5TJwtQcjgv
 -4OGfgeS3EKIFvCPac>
X-ME-Received: <xmr:RiOPZveui2AzAqXDT3AT_i8iPfV6WLPUm0uCXcFeHCrzZonAWyPqKjSE-bdcy3cReZ7D>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfeefgdefvdcutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
 rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
 gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
 heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
 hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:RiOPZlLVQl249LMuGa7mnfzEaZkQc7QzxD0vdangQwHz5rM6EUVfHQ>
 <xmx:RiOPZkJE-MB15HcLra4kVnkErpKb9BDWHcj8njy9oTMD6cm2EKiYtg>
 <xmx:RiOPZmz4xuAwgY3FCdynCh4NOyygB7KeQhzvzk85XoWgb2cTqGsm-w>
 <xmx:RiOPZoJfFpbc_viyc2nlR0R7Pv0JlH4cZURAa_4NJso8oL907X21jg>
 <xmx:SCOPZo1_NW8RurV51_kSFORJL9eIDzopASMBShuoKBvOclEIW0BeqfFl>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 10 Jul 2024 20:11:50 -0400 (EDT)
Message-ID: <0ce21379-70a7-4859-9f3f-2f88d23dccbc@HIDDEN>
Date: Thu, 11 Jul 2024 03:11:46 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <8634ohnwpz.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 10/07/2024 17:32, Eli Zaretskii wrote:
> In my book, prompting the user with the like of
> 
>    Project FOO disappeared, continue killing its buffers?

Without a change like the proposed, we don't have access to any FOO (the 
hook simply will return nil), so that's not something the general code 
can do.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 11 Jul 2024 00:19:02 +0000
Resent-Message-ID: <handler.72019.B72019.172065713825510 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN>
Cc: 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172065713825510
          (code B ref 72019); Thu, 11 Jul 2024 00:19:02 +0000
Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 00:18:58 +0000
Received: from localhost ([127.0.0.1]:50566 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRhWU-0006dO-00
	for submit <at> debbugs.gnu.org; Wed, 10 Jul 2024 20:18:58 -0400
Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]:60039)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1sRhWS-0006d9-B3
 for 72019 <at> debbugs.gnu.org; Wed, 10 Jul 2024 20:18:56 -0400
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailfhigh.nyi.internal (Postfix) with ESMTP id 9B4521140AA4;
 Wed, 10 Jul 2024 20:18:51 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Wed, 10 Jul 2024 20:18:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to; s=fm1; t=1720657131;
 x=1720743531; bh=0GtM6Ogf50st+0BFiDpavtdExsiF0SClfpZAL65uYfM=; b=
 IpgecCjRHtj6q5G+DtOTuAcnnb0BGfLOQUqDV/Fw2EtYec4U7OABrgo1p/ORGUdr
 layMfwqYFB8lDdMnPWvtOkq/TzGYYrh1AhGusYAlIc5zBuiAvH7SAnRa/O3g+BwU
 oTNf1i8jUoXZDEdsu9sV+dSuB1E3aVxUVoaloQTbytht+/cla1C4BZc8yAq+gYeK
 1w7hMrEymZcGLG9n35835R5YSe5X3l4mOUmiDaP8bfpTxGfhr//FeP/8u6EG3Vgi
 sgvxZdSvOOMTpNnS0UVOfMN5/Cim8TrY3I2IjnREF95zXj4l+m2ctsoZhDI2i/mu
 1V0HFTNwTVWI/bVv3udEzA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720657131; x=
 1720743531; bh=0GtM6Ogf50st+0BFiDpavtdExsiF0SClfpZAL65uYfM=; b=C
 0tuvPo0ci9fPP0wqNXI0At0ijHYEqfq2LFn1T+8p5hoqRw8pK/7s10FGPv/7B7/b
 tZ3JWIGbZRYYhfkOFGFmo5cbkNWSRnxNAekWGnk4lcPztQCcZCug/qgII+KYcD8P
 OEAdnUxCskVHQexXrWgTg7v9FE/KLwxZG4sS+WJqBXV0k3TPK2IVtPMxmdJtLgWo
 m0Qsa1/BnuIFbvMIif9HnO8GS1lmcNl3OjgmrOZX1TrsJvv8h+LyI1cRRptNzXd9
 cBy8m3uu3oUuZeOv+g4hhPWb6WlaYJJFz3PwsHT/ghsp/JnZjwH+a1f+87S17BaB
 T9jHr+BfipIyVjuIN4NZg==
X-ME-Sender: <xms:6iSPZmqbVNjnPBNqMGMjP68XctQvebD--2abSycR1aSnWGMcxmOqPg>
 <xme:6iSPZkqEVZn6jwX17J4GzHehk_Y1Uhwmf6XfKILKUrhlfQ3PqH_dBrEAprIzFY2V4
 xT90vhTMMrwwBBoVHU>
X-ME-Received: <xmr:6iSPZrMn3DXuDXzHwgnZe_xirkQJ1oUyFV3zQtq-7RwG7QYjFEBM-OEL-Mwd2sLfYrNa>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrfeefgdeffecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihht
 rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
 gvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudej
 heenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
 hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:6iSPZl4lT9JOVMGHacG3ez4TCMJKZjSTEES8AekfsGNDmnaEmq9YWg>
 <xmx:6iSPZl4hMdpekD9xKVcApur1WunnxP4F2zlg-7jEGSa1kG_N4F8hQA>
 <xmx:6iSPZlhFdNKAM6w9OS8xBMzonl1azSkjqh3uwpGNpW_-5YihYaLBqA>
 <xmx:6iSPZv4njMHe6SVurT8kBhJ6kVAQ7850XU68cuJnyeTvTKB_JrqeBQ>
 <xmx:6ySPZvn9buvjl7CP6GxWzw2q6OKFUyu7TxDbV9QVpbeca9iRgZe_CddH>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 10 Jul 2024 20:18:49 -0400 (EDT)
Message-ID: <5c12905c-370e-419b-8ff1-657341da68cf@HIDDEN>
Date: Thu, 11 Jul 2024 03:18:46 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
 <86zfqpm9ur.fsf@HIDDEN> <iera5ipi1nz.fsf@HIDDEN>
 <86v81dm8te.fsf@HIDDEN> <ier7cdthzh1.fsf@HIDDEN>
 <86sewhm5ri.fsf@HIDDEN>
Content-Language: en-US
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <86sewhm5ri.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On 10/07/2024 22:00, Eli Zaretskii wrote:
>> Because it is also nicer to explicitly indicate what project the Lisp
>> program is operating on.  Going through project-current means there are
>> a number of possible bugs.  Lisp programs should pass in the project
>> instance; this is preferred for new project.el-using code.
> If this is the current trend in project.el development, then I have no
> objections to it.  I find it a bit surprising that the original
> motivation for this was something completely different, though.

I don't know if it's going to be a big direction, but the logic seems 
sound for a command like this.

The original choice was more or less arbitrary. The change in the patch 
is backward-compatible, so it shouldn't hurt.

The particular benefit scenario that I can see is this:

* The project directory has been deleted, but a number of its buffers it 
still around.
* So it doesn't seem feasible to compute the project instance 
automatically (the project markers are gone, etc).
* But if something has held onto a project object, its method 
(project-buffers) might feasibly complete without errors.

For project-kill-buffers in particular it seems like a real advantage - 
getting to clean up buffers belonging to an already deleted project. And 
if one step 2 or 3 fails with an error, oh well, it doesn't seem like we 
could have done better.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 11 Jul 2024 04:51:02 +0000
Resent-Message-ID: <handler.72019.B72019.172067342617711 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: sbaugh@HIDDEN, 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172067342617711
          (code B ref 72019); Thu, 11 Jul 2024 04:51:02 +0000
Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 04:50:26 +0000
Received: from localhost ([127.0.0.1]:50710 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRllB-0004bb-TN
	for submit <at> debbugs.gnu.org; Thu, 11 Jul 2024 00:50:26 -0400
Received: from eggs.gnu.org ([209.51.188.92]:51520)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRll9-0004bO-7C
 for 72019 <at> debbugs.gnu.org; Thu, 11 Jul 2024 00:50:24 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRll4-0006Jw-2P; Thu, 11 Jul 2024 00:50:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=Gi20eMID54lPXCaCRxaIT4+9lopIFxNDe0hvkvj+rKQ=; b=B3UoVa7/lwGw
 oPNMl1AUDBr9X/FIPWUjNOhqfeU/dAwVUbkZwmxk3aMokV0d5/DOdiwufIwT5Hfk1pRyb3TaoMlYl
 3wgaRPf5LrE03qIm/ox1S/1Zp6suxmcnhrzJRG4eFg0aZqg5B2MLqzGRaaPxzV/8ORQSj4JvWEa3L
 Mve7WFlNwW1kpNURG8ibjgbRN9ZWfwDQff8OB9Ajrevns/8z4KDnCayb9Mut75kVZnKw007b8ve1j
 rJ0fZ2xmqDiDAPDJ4++l6NliwcbeHJFlpOmZfRT89dTxW+oU05uxdEexzfQmABz26o2Vo9QoA6t1T
 BBP0l0OsoHGedQkAT5voIg==;
Date: Thu, 11 Jul 2024 07:50:04 +0300
Message-Id: <86le28mt1f.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <0ce21379-70a7-4859-9f3f-2f88d23dccbc@HIDDEN> (message from
 Dmitry Gutov on Thu, 11 Jul 2024 03:11:46 +0300)
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <0ce21379-70a7-4859-9f3f-2f88d23dccbc@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 11 Jul 2024 03:11:46 +0300
> Cc: 72019 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry@HIDDEN>
> 
> On 10/07/2024 17:32, Eli Zaretskii wrote:
> > In my book, prompting the user with the like of
> > 
> >    Project FOO disappeared, continue killing its buffers?
> 
> Without a change like the proposed, we don't have access to any FOO (the 
> hook simply will return nil), so that's not something the general code 
> can do.

That's a minor issue that can be easily handled by fine-tuning the
message.  For example:

  Current project disappeared, continue killing its buffers?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#72019: [PATCH] Add project argument to project-kill-buffers
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 11 Jul 2024 04:54:02 +0000
Resent-Message-ID: <handler.72019.B72019.172067358717948 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72019
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: sbaugh@HIDDEN, 72019 <at> debbugs.gnu.org
Received: via spool by 72019-submit <at> debbugs.gnu.org id=B72019.172067358717948
          (code B ref 72019); Thu, 11 Jul 2024 04:54:02 +0000
Received: (at 72019) by debbugs.gnu.org; 11 Jul 2024 04:53:07 +0000
Received: from localhost ([127.0.0.1]:50715 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sRlnn-0004fQ-C9
	for submit <at> debbugs.gnu.org; Thu, 11 Jul 2024 00:53:07 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41050)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sRlnk-0004ev-Iy
 for 72019 <at> debbugs.gnu.org; Thu, 11 Jul 2024 00:53:05 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sRlnf-0008PZ-Ot; Thu, 11 Jul 2024 00:52:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=k6h3uckj7zD/TduapC8SkLUzg7PMIHvOdGq3a0HxoFo=; b=QYMH3b2IY4Ov
 +nuCoFE2d/6zIufooxPh5d0H/S+5bjhOR/lUFo4Fb5mX6hUCVVMLKvERePgU4VOTpeBjv5GTyBl8W
 HiUBuogs4ivIfRABjDk4SmIc8KHYdWWykCdFcN8ohV/BUAqCpeZKCHSEE3fXdY36gIDldq+LviSYz
 KNI7E9vppA+Ps2Rh0ku1sqPmBM1XJj9xl3Qwr+blMTinrEUgiDmC/G2SxOirlEc6BCcWEYeFi2teO
 SFcxcvs0Mb9VHo5tlTQ6S54fERPa2rwdma0HXzDue9rinH3bNHQA+HtxfPjfsN+AJBu0EJxME84A1
 tk7RSBOLvgn0QsY/Lu2c9A==;
Date: Thu, 11 Jul 2024 07:52:56 +0300
Message-Id: <86jzhsmswn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <5c12905c-370e-419b-8ff1-657341da68cf@HIDDEN> (message from
 Dmitry Gutov on Thu, 11 Jul 2024 03:18:46 +0300)
References: <ierfrsiifio.fsf@HIDDEN> <86ed81o5oc.fsf@HIDDEN>
 <CAO=BR8P=LyNQePFpQNhcymiK4QT2ZGq800LP0PEnw_NhYixV5Q@HIDDEN>
 <8634ohnwpz.fsf@HIDDEN> <iercynli6zf.fsf@HIDDEN>
 <86zfqpm9ur.fsf@HIDDEN> <iera5ipi1nz.fsf@HIDDEN>
 <86v81dm8te.fsf@HIDDEN> <ier7cdthzh1.fsf@HIDDEN>
 <86sewhm5ri.fsf@HIDDEN> <5c12905c-370e-419b-8ff1-657341da68cf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 11 Jul 2024 03:18:46 +0300
> Cc: 72019 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry@HIDDEN>
> 
> On 10/07/2024 22:00, Eli Zaretskii wrote:
> >> Because it is also nicer to explicitly indicate what project the Lisp
> >> program is operating on.  Going through project-current means there are
> >> a number of possible bugs.  Lisp programs should pass in the project
> >> instance; this is preferred for new project.el-using code.
> > If this is the current trend in project.el development, then I have no
> > objections to it.  I find it a bit surprising that the original
> > motivation for this was something completely different, though.
> 
> I don't know if it's going to be a big direction, but the logic seems 
> sound for a command like this.
> 
> The original choice was more or less arbitrary. The change in the patch 
> is backward-compatible, so it shouldn't hurt.
> 
> The particular benefit scenario that I can see is this:
> 
> * The project directory has been deleted, but a number of its buffers it 
> still around.
> * So it doesn't seem feasible to compute the project instance 
> automatically (the project markers are gone, etc).
> * But if something has held onto a project object, its method 
> (project-buffers) might feasibly complete without errors.
> 
> For project-kill-buffers in particular it seems like a real advantage - 
> getting to clean up buffers belonging to an already deleted project. And 
> if one step 2 or 3 fails with an error, oh well, it doesn't seem like we 
> could have done better.

My question for this scenario would be: does project.el support it in
general?  I'd expect quite a few of the functions to rely on the fact
that the project directory is there, in which case this is the tip of
a very large iceberg.

But you know the code and the design much better than I do, so if it
makes sense to you, fine.

Last modified: Thu, 11 Jul 2024 05:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.