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

[Stephen Leake <stephen_leake@stephe-leake.org>]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>> A generic like project-contains?
>> That's one option, with the current predicate in
>> project--buffer-list as
>> the default implementation; then I could override that to check
>> project-files, or all roots, or something. As long as it passes C-u to
>> the backend, my function could also use that to decide about dependent
>> libraries.
>
> 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.

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

And no, not all project files can be distinguished by directory; I have
files in the same directory that are managed by different projects (Ada
and elisp).

>> It might be better to make the predicate more specific;
>> project-delete-this-buffer-p. That way eglot won't try to abuse
>> project-contains to pick a server :). Or maybe my delete buffer case
>> and eglot's "choose the right server" case really are the same?
>
> 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.

>> I think another generic project-name, or possbly project-prompt,
>> would
>> be good here. The default could be project-root.
>
> We can add that, but please file that as a separate bug report.

Done; 48747

>> There should also be a custom boolean to turn off the prompt; it's
>> helpful the first few times, then it's just annoying. Currently C-u is
>> 'no-confirm'; I hope that will change to 'no-dependencies'.
>
> It *might* change to "include dependencies", since currently it's not
> supposed to include them.
>
> 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".

-- 
-- Stephe