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

[Philip Kaludercic <philipk@posteo.net>]

In general I'd like to remind everyone of the GNU Kind Communication
Guidelines, because the tone of the discussion in this issue report has
been unpleasant for a few days now.

João Távora <joaotavora@gmail.com> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>>> I've explained to Philip objective reasons why I think evaluated
>>> mini-languages are almost always inferior to a decent Lisp such as Elisp.
>>> You could perfectly reasonably deprecate these two variables.
>> Not where this discussion is going, is it?
>
> Not sure.  This started has a report of hidden buffer being incorrectly
> killed by project.el.  

The issue that was reported was that Eglot/jsonrpc raised an error that
broke `project-kill-buffer'.  This could have also all been solved by
wrapping a `with-demoted-errors' around `kill-buffer'.

>                        After much insistence, you've agreed to plug the
> hole in that library.  During tests I also discovered that project.el is
> killing other buffers nonsensically, like Gnus buffers, *ibuffer*, and
> many other global.  It was actually easier to find false-positives of
> your heuristic than true ones.  Again, after some insistence, you seem
> to have come around that these things represent bugs.
>
> Three people here have suggested an opt-in approach for the true
> positives.  Now your strategy seems to be "OK: let all these false
> positives remain nonsensically associated with a project in
> project-buffers but let's have global databases of exceptions for
> specific operations, using a (largely redundant) mini-language for
> buffer-matching".

For the record, I am still not convinced 100% either way.  Whether or
not whitelisting or blacklisting is the better approach will concretely
depend the list of misjudgments that the current condition makes.

> If that doesn't sound like a bad idea in the face of much better other
> ideas, I don't know what else to tell you.
>
>>>  > I'm fairly sure that the solution I offered would be easy enough
>>>  > implement, to actually protect the vulnerable buffer.
>>>  > I suppose we are not doing that, however.
>>> You sketched an untested code-less idea and I explained how flawed
>>> it was.
>>
>> Back atcha. Modulo "code-less".
>
> Not only did I provide code, I also verified that it works.  Anyone can
> see my messages to verify that.
>
> João