bug#72019: [PATCH] Add project argument to project-kill-buffers

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Spencer Baugh]

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

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-project-argument-to-project-kill-buffers.patch --]
[-- Type: text/patch, Size: 1885 bytes --]

From 5fdd9735148a5b009c0a2a4339c88bf8ab177f37 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@janestreet.com>
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

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Dmitry Gutov]

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?

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> Date: Tue, 9 Jul 2024 22:59:46 +0300
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> 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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Spencer Baugh]

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

On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Spencer Baugh <sbaugh@janestreet.com>
> > 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.

>

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

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 10 Jul 2024 09:27:06 -0400
> Cc: 72019@debbugs.gnu.org
> 
> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  > From: Spencer Baugh <sbaugh@janestreet.com>
>  > 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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Wed, 10 Jul 2024 09:27:06 -0400
>> Cc: 72019@debbugs.gnu.org
>> 
>> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>>  > From: Spencer Baugh <sbaugh@janestreet.com>
>>  > 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 it keeps happening, I'll send a future patch which further improves
things.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 72019@debbugs.gnu.org
> Date: Wed, 10 Jul 2024 11:47:48 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Spencer Baugh <sbaugh@janestreet.com>
> >> Date: Wed, 10 Jul 2024 09:27:06 -0400
> >> Cc: 72019@debbugs.gnu.org
> >> 
> >> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >> 
> >>  > From: Spencer Baugh <sbaugh@janestreet.com>
> >>  > 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?

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 72019@debbugs.gnu.org
>> Date: Wed, 10 Jul 2024 11:47:48 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Spencer Baugh <sbaugh@janestreet.com>
>> >> Date: Wed, 10 Jul 2024 09:27:06 -0400
>> >> Cc: 72019@debbugs.gnu.org
>> >> 
>> >> On Wed, Jul 10, 2024, 7:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
>> >> 
>> >>  > From: Spencer Baugh <sbaugh@janestreet.com>
>> >>  > 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?

I don't need this to be on the release branch.  I'd prefer to add the
argument and just keep this on master.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 72019@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?

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 72019@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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 72019@debbugs.gnu.org
> Date: Wed, 10 Jul 2024 14:30:02 -0400
> 
> Eli Zaretskii <eliz@gnu.org> 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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Dmitry Gutov]

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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> Date: Thu, 11 Jul 2024 03:18:46 +0300
> Cc: 72019@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Dmitry Gutov]

On 11/07/2024 07:52, Eli Zaretskii wrote:

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

I'm not sure. Hence I'm not announcing a big switchover for every 
command, or anything like that. But the command "kill all buffers" seems 
like a very good fit for a project that's not there anymore.

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

This particular decision is ad-hoc, but it does seem like it has no or 
very little drawbacks.

Let me know if it's okay for emacs-30, or we should postpone it to master.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> Date: Thu, 11 Jul 2024 22:47:57 +0300
> Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> Let me know if it's okay for emacs-30, or we should postpone it to master.

I prefer master.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Dmitry Gutov]

On 12/07/2024 08:48, Eli Zaretskii wrote:
>> Date: Thu, 11 Jul 2024 22:47:57 +0300
>> Cc:sbaugh@janestreet.com,72019@debbugs.gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> Let me know if it's okay for emacs-30, or we should postpone it to master.
> I prefer master.

Thank you, now pushed to master, and closing.

Let's see if any problems come up with this solution.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Dmitry Gutov]

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.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> Date: Thu, 11 Jul 2024 03:11:46 +0300
> Cc: 72019@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> 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?

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Dmitry Gutov]

On 11/07/2024 07:50, Eli Zaretskii wrote:
>> Date: Thu, 11 Jul 2024 03:11:46 +0300
>> Cc:72019@debbugs.gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> 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?

We would basically never be killing "its" buffers after that - so the 
proposed message seems misleading.

bug#72019: [PATCH] Add project argument to project-kill-buffers

[Eli Zaretskii]

> Date: Thu, 11 Jul 2024 22:44:55 +0300
> Cc: sbaugh@janestreet.com, 72019@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 11/07/2024 07:50, Eli Zaretskii wrote:
> >> Date: Thu, 11 Jul 2024 03:11:46 +0300
> >> Cc:72019@debbugs.gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> 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?
> 
> We would basically never be killing "its" buffers after that - so the 
> proposed message seems misleading.

Feel free to propose a different text.  My main point is that it
should not be too hard to come up with a message that is both accurate
and helpful, in the sense that the user can decide what to do in this
situation.