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

[Eli Zaretskii <eliz@gnu.org>]

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