GNU bug report logs - #72019
[PATCH] Add project argument to project-kill-buffers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72019 in the body.
You can then email your comments to 72019 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add project argument to project-kill-buffers
Date: Tue, 09 Jul 2024 14:31:11 -0400

[Message part 1 (text/plain, inline)]

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

[0001-Add-project-argument-to-project-kill-buffers.patch (text/patch, attachment)]

Message #8 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, 72019 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Tue, 9 Jul 2024 22:59:46 +0300

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 #11 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 14:19:31 +0300

> From: Spencer Baugh <sbaugh <at> 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.

Message #14 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 14:43:19 +0300

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

Message #17 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 09:27:06 -0400

[Message part 1 (text/plain, inline)]

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

> > From: Spencer Baugh <sbaugh <at> 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.

>

[Message part 2 (text/html, inline)]

Message #20 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 17:32:56 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> 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 <at> gnu.org> wrote:
> 
>  > From: Spencer Baugh <sbaugh <at> 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.

Message #23 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 11:47:48 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> 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 <at> gnu.org> wrote:
>> 
>>  > From: Spencer Baugh <sbaugh <at> 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.

Message #26 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 20:32:12 +0300

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

Message #29 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 13:42:40 -0400

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

Message #32 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 20:54:37 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> 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 #35 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 14:30:02 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> 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 #38 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Wed, 10 Jul 2024 22:00:33 +0300

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

Message #41 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Thu, 11 Jul 2024 03:11:46 +0300

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 #44 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Thu, 11 Jul 2024 03:18:46 +0300

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 #47 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Thu, 11 Jul 2024 07:50:04 +0300

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

Message #50 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Thu, 11 Jul 2024 07:52:56 +0300

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

Message #53 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Thu, 11 Jul 2024 22:44:55 +0300

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

Message #56 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Thu, 11 Jul 2024 22:47:57 +0300

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.

Message #59 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Fri, 12 Jul 2024 08:47:14 +0300

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

Message #62 received at 72019 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 72019 <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Fri, 12 Jul 2024 08:48:37 +0300

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

I prefer master.

Message #67 received at 72019-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 72019-done <at> debbugs.gnu.org
Subject: Re: bug#72019: [PATCH] Add project argument to project-kill-buffers
Date: Tue, 16 Jul 2024 05:00:50 +0300

On 12/07/2024 08:48, Eli Zaretskii wrote:
>> Date: Thu, 11 Jul 2024 22:47:57 +0300
>> Cc:sbaugh <at> janestreet.com,72019 <at> debbugs.gnu.org
>> From: Dmitry Gutov<dmitry <at> 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.

Previous Next

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