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

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Sorry, I don't have Eglot checked out, or the time to test out the
> patch.

If you missed it, Eglot has been merged in lisp/progmodes/eglot.el.
There's not much point in testing that your patch: I can tell you right
away it doesn't work.

> I suppose. But the current criterion depends on the value of
> default-directory, and that makes it a match.

This criterion is wrong.  It makes mistakes.  But a criterion that is
"default-directory and is not hidden", though probably still not ideal,
but is definitely better.

>> If you agree that
>> there are such cases, then it should become clear that the buffer in
>> question must be at the top of that list.
>
> I'm not sure. Intuitively, I'd say that this buffer belongs to the
> project because it "services" the project. But if it were to work for
> several projects at the same time, I suppose I could say it doesn't
> belong to any particular one.

It indeed indirectly services just that one project: but it's also just
another object.  Eglot has lots of objects, variables etc., that
"service the project" and project.el fortunately isn't crazy to to touch
them.  The buffer in question is an implementation detail of jsonrpc.el.
It's not a buffer of interest in any way for the user or project.el's
manipulations.  And it's only a buffer because buffer's are Emacs'
common way of communicating with external entities, and jsonrpc.el uses
that technique.  But it could use some other way, say another
process-filter or function calls into C code of a dynamic library.
There would also be objects that indirectly "service" the project, but
not buffers.

>> There are more hints that the concept of "buffer belonging to a project"
>> was not fully thought through, even in cases unrelated to this bug
>> report.
>> * Take the *scratch* buffer.  It has a default-directory.  Does this
>>    also make *scratch* belong to a project?  It doesn't make any sense to
>>    me that it would.  Yet it is caught by project-buffers.
>
> *scratch* is not that special - you can create similar buffers at
>  will. So there are two ways of looking at that question. One can
>  create a "scratch" for a project, and it will be part of that
> project.
>
> If "~" (the usual value of default-directory in the original
> *scratch*) belongs to a project, then *scratch* also does.

I M-x cd in *scratch* all the time.  It's a global scratch pad,
now accessible via scratch-buffer everywhere.

>> * project-buffers also catches the one-time *Completions* buffers, the
>>    kind produced by hitting TAB after C-x p b.  If you type C-x p b
>>    again, it quite comically offers the stale *Completions* buffer as a
>>    candidate to switch to.
>
> We could make an exception for that too.
>
>> But back to *scratch*.  Somehow *scratch* is not killed by M-x
>> project-kill-buffers.  I think it's because it doesn't have a
>> buffer-file-name.  But then neither does the Eglot/Jsonrpc's "background
>> buffers"!  It seems it is being targeted merely because it uses
>> fundamental-mode, a most reasonable mode to use for exchanging messages
>> via standard streams.
>> I guess this means that the hack below is enough to fix the issue,
>> but
>> it is also decidedly silly.
>
> It's not much better than adding a function to
> kill-buffer-query-functions that returns nil. And/or behaves
> accordingly to eglot-autoshutdown.

You should think your solution through before comparing with the ones
provided so far, which have been tested.  Where in the source code would
you even set kill-buffer-query-functions?  Eglot code in jsonrpc.el??
Not to mention duplicating the eglot-autoshutdown check in unrelated
places is pretty ugly.

>> So please consider fixing this in project.el.  As Manuel pointed out,
>> the venerable ibuffer.el's ibuffer-kill-filter-group also kills project
>> buffers and handles this whole thing very well.  We should just take a
>> hint from it.
>
> I'm unable to find that message.

In the original conversation: 

https://github.com/joaotavora/eglot/discussions/822#discussioncomment-2053395