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:

> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..1e7573c740 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -1223,7 +1223,9 @@ project-display-buffer-other-frame
>  (defcustom project-kill-buffer-conditions
>    '(buffer-file-name    ; All file-visiting buffers are included.
>      ;; Most of the temp buffers in the background:
> -    (major-mode . fundamental-mode)
> +    (and
> +     (major-mode . fundamental-mode)
> +     (not "\\` "))
>      ;; non-text buffer such as xref, occur, vc, log, ...
>      (and (derived-mode . special-mode)
>           (not (major-mode . help-mode)))

Thanks.  If that works, go ahead and push it.

This should work around this specific bug and then we can open another
one to follow up on all the disaster that has unfolded since.

>> In the little time I've used this feature since the start of this
>> discussion I have discovered it backfires no small number of occasions:
>> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
>> even *ibuffer* itself is targeted by this.
> Of course it is targeted: we want ibuffer buffers to be killed just as
> well when killing a project. And sly-scratch, and etc.

No, we don't want.  *sly-scratch* is a global scratchpad for the Common
Lisp connection that can "service" many Common Lisp projects, to use
your own terminology.

Do you know what M-x ibuffer does? It's a manager for all the buffers in
all the projects in Emacs.  In the earmuffed *ibuffer*, it gives you an
overview of all visited buffers, sorted and organized by various
criteria.  Again, *ibuffer* can't possibly be taken to "service a
project".  Destroying this buffer's state because the user decided to
kill a project is simply wrong.  It's very plain to see that.

And *Shell Command Output* where it is impossible to know in advance if
the contents refer to a specific project or not.  It depends on what the
user typed after M-|!

And the Gnus buffers?  And the CIDER report?

>> you're making a gun that only backfires 5% of the time.
> Yours is the first instance so far.

We seem to use different algebraic systems.

>> The mini-languages invented in project-kill-buffers-conditions and
>> project-ignore-buffer-conditions are abominations.
> This is the point where I'd normally blacklist you again.

I had no idea who authored those variables.  If you are among the
authors, I'm very sorry, I was referring merely to code.  I said before
I'm quite happy with project.el, but this (small) part of it is very
badly done.

> They are not much better than the "patch" I showed for Eglot,
> correctness-wise.

Of course they are, they are opt-in.  So project.el's C-x p k doesn't
destroy packages' essential buffers just because of some overly greedy
heuristic.  Using this idea, we make a conservative heuristic better, on
a case by case basis.

> And mine would make it safe against any kill-buffer calls, including
> ones issued by the user.

Should I really to explain again that a hidden buffer is hidden from the
user and thus he can't reasonably M-x kill-buffer on it?