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

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

Philip Kaludercic <philipk@posteo.net> writes:

> What would be a co-owner?
>
> My view is that project.el is a manager of buffers, but that isn't
> relevant anymore.

You almost answered the question.  There is more than one manager of
buffers.  Ibuffer manages buffer, M-x buffer-list, the user.  Eglot
manages some normal source code buffers in a co-owned way.

In contrast, the JSONRPC stdout and stderr hidden buffers are managed by
no-one else other than jsonrpc.el: they're not co-owned.

> Project.el uses the same condition format like `buffer-match-p', which
> is quite flexible.  Maybe all earmuffed buffers should be spared
> ("\\`\\*.+\\*\\'"), but in my experience that can be too lenient.

Yes, I think some earmuffed buffers can clearly belong to projects.
Others probably not.  You haven't seen me complain about
project-kill-buffers killing the *EGLOT events* buffer, for example ;-)

That is not a hidden/private buffer, so I accept that other buffer
managers kill it.

> I have to still admit that I am uncertain if the general ignoring of all
> hidden buffers is justified.

Notice that the patch is more tame: only hidden buffers without
buffer-file-names are exempted from project-buffers.

> I have certainly used hidden buffers
> frequently enough but never assumed that they were outside of anyone's
> control.

What have you used them for?

> They are just regular buffers with a special kind of name
> after all.

I don't know any "irregular" buffers, but yes, that is their
representation.  This representation is an old convention in Emacs for
"out of bounds" and "out of sight".

> We ought to be able to define a cleaner way of clarifying what buffers
> can and cannot belong to projects.

Agreed.

> Personally I think a buffer-local variable/predicate would be a better
> approach.

You can think about new conventions and protocols but you force it down
existing package's throats.  That doesn't go well as this bug shows.
That's because there are many diverse packages out there, that you can't
possibly know about and they likely aren't tracking your developments
and your thinking.

Have you considered the converse approach which is to be conservative?
It doesn't have these drawbacks.  In your project buffer's bucket put
only non-earmuffed, non-hidden, file-visiting buffers automatically.
Those are relatively safe.  Then have a buffer-local variable for
packages to opt into -- not opt out of -- your scheme.

As project.el and its new commands gain popularity (I hope it does) then
more and more packages, major-modes, etc will want to buy into its API
and add a little (setq-local project-owned t) when they setup their
helper buffers.  It takes a bit more marketing work, but in the end it's
better.