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:

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

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