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

[Dmitry Gutov]

On 31.10.2022 22:58, João Távora wrote:
> 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.

I suggest you try it first.

Last time I launched Eglot was around several months ago.

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

Disaster, really?

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

Okay, you're probably right about at least some of those.

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

I must have been thinking about project-* or projectile-* counterparts.

Like projectile-ibuffer or the homemade version for project.el made by a 
user in a bug report nearby.

> 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?

Do you know whether CIDER will be satisfied by the same patch I sent 
previously?

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

This is literally the first bug report on the subject.

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

I'm not the only author. Regardless, it's not a good language to use no 
matter who wrote it.

What you are doing is pressuring all other participants into your POV by 
means of an insult. That usually works better if the offending code was 
written by somebody who already left (the project/the discussion/the 
company/etc), or is a little younger.

> > 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?

They can, though, even if odds are low. It can also happen through some 
other automation, which Emacs lets the users do freely.

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.