Re: [PATCH] Speed up project-kill-buffers

[Dmitry Gutov]

Hi Stephen,

I've posted a patch to 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49264#38 which should add 
the necessary flexibility, for your project backend to be able to list 
its buffers without being tied to the root dir.

So far it just adds a generic called 'project-buffers'.

On 30.05.2021 20:51, Stephen Leake wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> > I'm fairly sure you don't want to close the buffers visiting the
> > dependencies.
>
> Sometimes I do; I'm done working on ada-mode, and I transition to
> working on my music database, closing all ada-mode related files. Other
> times I don't; I found a bug in ada-mode, so I move to the wisitoken
> library to run tests there, closing only the higher-level ada-mode
> files.
>
> The point is that it is up to the user, to decide on a case by case
> basis.

If the distinction is indeed useful, maybe the change mentioned above 
can be followed with generic 'project-externals-buffers'.

Either way, it seems you might prefer a new command like 
'project-kill-other-buffers' (as opposed to 'project-kill-buffers'), 
which would kill all buffers (which satisfy 
project-kill-buffer-conditions, of course) that don't belong to the 
current project.

> > Or if we do, that would be a globally acting modifier, and that piece
> > of logic which we would add to project-kill-buffers would just see
> > whether the buffer's default-directory is inside any of the "external
> > roots", as defined by the backend. Would that work for you?
>
> I don't follow. What is the UI? How does the information given by the
> user get passed to the backend? Only the backend can interpret
> "dependencies".

Yeah, scratch that.

> > I'd rather we try to be more strict with semantics, if possible, and
> > 'project-contains?' would only return t for buffers "inside" the
> > project, not stuff that's outside but related to it (like external
> > libraries, system includes, etc, which is what I'd like "external
> > roots" to be targeted at).
>
> Then you need an "include-external-roots" arg to project-contains, since
> sometimes that's what the user wants.

For now it's project-buffers and (potentially) 
project-externals-buffers, for nicer naming and being able to implement 
in the vc backend in a performant fashion more easily (having predicate 
methods would require caching some information in the project instance 
between the calls).

But project-contains-buffer-p and project-externals-contain-buffer-p are 
still on the table, if anybody feels strongly about that choice.

> > If you want this change to happen, could you outline the cases when
> > you would and would not use this capability? Personally, I'd probably
> > never kill those buffers.
>
> I gave examples above. In general, if I'm switching to a project that
> shares some files with the current one, I don't want to delete those
> buffers. So the correct semantics would be "switching from project A to
> project B; close all non-shared buffers".

Sounds like 'project-kill-other-buffers' I described above. You might 
not even need to make a distinction between project contents and 
"externals" for this scenario (having 'project-buffers' return all 
pertinent buffers).

But there can be other scenarios, I guess.