GNU bug report logs - #58839
29.0.50; project-kill-buffer fails when Eglot is running

Previous Next

Full log

Message #179 received at 58839 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58839 <at> debbugs.gnu.org,
 manuel.uberti <at> inventati.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
 fails when Eglot is running
Date: Tue, 01 Nov 2022 18:44:44 +0000

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 01.11.2022 13:27, Philip Kaludercic wrote:
>
>> I am biased, but I believe that the language could even find more use in
>> project.el, by having `project-buffers' just call `match-buffers' with a
>> special `buffer-match-p' predicate.  Here is a sketch of how that could
>> look like (I haven't tested it yet):
>
> 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

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

>> +(defcustom project-buffer-conditions
>
> Why not keep considering unknown buffers as part of project by default?

What are "unknown buffers"?

> 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?

>> +  '(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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.