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

[Spencer Baugh <sbaugh@janestreet.com>]

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.