bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running

[Dmitry Gutov <dgutov@yandex.ru>]

On 01.11.2022 22:10, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 01.11.2022 20:44, Philip Kaludercic wrote:
>>
>>>> Sure, but only after we're ready to drop project.el support for Emacs
>>>> older than 29.
>>> The functionality can be provided using Compat[0], as is already
>>> done for a
>>> few core package that are distributed on GNU ELPA (ERC, python-mode).
>>> [0] https://elpa.gnu.org/packages/compat.html
>>
>> I suppose if the performance improvement is shown to be significant,
>> we could. I'm a little hesitant to add a new dependency: I haven't
>> been following this package, not sure how stable it is.
> 
> I am the maintainer, so I am biased, but stability is a high priority,
> which is why the library is extensively tested, where-ever possible:
> 
> https://git.sr.ht/~pkal/compat/tree/master/item/compat-tests.el
> 
> Fun fact, I came up with the idea for this library when working on
> project-kill-buffer over two years ago, as a means of extracting the
> language out of project.el, as has been done with buffer-match-p.

Oh ok. I suppose I don't mind, then.

It would be nice to have some benchmark, however, at what number of 
buffers the optimization brings some perceptible difference (like, the 
delay is reduced by 50ms at least).

>>>>> +(defcustom project-buffer-conditions
>>>>
>>>> Why not keep considering unknown buffers as part of project by default?
>>> What are "unknown buffers"?
>>
>> Take whatever special buffer belonging to jsonrpc that was the cause
>> of this bug report. It can still be useful to be able switch to it
>> using project-switch-to-buffer (if, say, one was looking for the
>> specific buffer to try to debug a problem with some Eglot feature in
>> their project). We don't want to kill it with the rest of the buffers,
>> however. Apparently.
> 
> Ah, right.  I have to admit that I rarely use project-switch-to-buffer,
> so I forgot about that.  In that case, project-kill-buffer-conditions
> cannot be deprecated, as these are just a subset of the project buffers.

There can be other uses for 'project-buffers' as well, like the 
reimplementation of projectile-ibuffer in another bug report.

>>>> We'll just stop killing them on cleanup.
>>>>
>>>> Otherwise, we'll really need an extensible mechanism for major modes
>>>> all around the ecosystem to tag themselves as project-visible.
>>> Wouldn't a simple buffer local variable suffice?
>>
>> I guess it will. Only with a more meaningful name than 'project-owned'
>> and some proper documentation.
> 
> Right.  Does it have to have a "project-" prefix, or would
> "belongs-to-project" (hypothetically) be fine too?

Let's keep to the module-prefixing strategy. I think it makes sense, and 
the rest of the symbols in project.el are named that way.

>>>>> +  '(and (or buffer-file-name
>>>>> +            (derived-mode . compilation-mode)
>>>>> +            (derived-mode . dired-mode)
>>>>> +            (derived-mode . diff-mode)
>>>>> +            (derived-mode . comint-mode)
>>>>> +            (derived-mode . eshell-mode)
>>>>> +            (derived-mode . change-log-mode))
>>>>> +        project-includes-buffer-p)
>>>>> +  "A buffer predicate for matching what buffers belong to a project."
>>>>> +  :type 'buffer-predicate)
>>>>
>>>> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.
>>> This is my point, I think João is right that this ought to be an
>>> enumeration of major modes that are related to projects.  As this is a
>>> user option, users can add or remove whatever modes they disagree on and
>>> that behaviour would ideally be propagated to all projects.
>>
>> Being to customize it is a good thing.
>>
>> But either we provide a reasonably complete list which we regularly
>> update, or we say its completeness is up to the user.
> 
> I would want to argue that the complete list is preferable.

Then we'll have to keep updating it from time to time.

>> And in the latter case, as soon as the user customizes the var, they
>> stop getting any updates we might make to it later (to the default
>> value).
>>
>> And if we take the strict "whitelist" approach, I'm pretty sure the
>> list will require updating in the future, it will never be complete.
> 
> Which is fair, but which can also be combined with

(unfinished)