GNU bug report logs -
#58839
29.0.50; project-kill-buffer fails when Eglot is running
Previous Next
Full log
Message #182 received at 58839 <at> debbugs.gnu.org (full text, mbox):
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.
>>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>>> index ac278edd40..b55c245368 100644
>>> --- a/lisp/progmodes/project.el
>>> +++ b/lisp/progmodes/project.el
>>> @@ -352,15 +352,28 @@ project--remote-file-names
>>> (concat remote-id file))
>>> local-files))))
>>> +(defun project-includes-buffer-p (buffer dir)
>>> + "Return non-nil if the `default-directory' of BUFFER is below DIR."
>>> + (file-in-directory-p
>>> + (buffer-local-value 'default-directory buffer)
>>> + dir))
>>
>> Not an optimal name, given that we have made project-buffers a generic
>> function, so that a custom project backend can define their own
>> buffer-listing strategy. And this one implies that matching by
>> default-directory is universal.
>
> Right, as I said this is just a sketch.
>
> But as the diff showed, I think any more specific implementation ought
> to extend the generic implementation, by using `cl-call-next-method'
> instead of `buffer-list'.
Or apply the same filters some other way, I guess. But yes, the
cl-call-next-method call makes sense in your patch.
>>> +(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.
>> 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.
>>> + '(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.
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.
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.