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

[Eli Zaretskii <eliz@gnu.org>]

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