GNU bug report logs -
#58839
29.0.50; project-kill-buffer fails when Eglot is running
Previous Next
Full log
View this message in rfc822 format
On 01.11.2022 22:10, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov <at> 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)
This bug report was last modified 2 years and 279 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.