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

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Tue, 9 Jul 2024 18:32:01 UTC

Severity: normal

Tags: patch

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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




This bug report was last modified 312 days ago.

Previous Next


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