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

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

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> I suggest you try it first.

It works in my test

> Disaster, really?

The reason I came about the Gnus problem was when using it
to reply to some emails here and trying out the C-x p k and finding out
all my Gnus buffers were gone.

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

No.  I don't use it. You should ask Manuel, who reported this in
the original discussion.

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

It's Philip's bug report.  I don't use C-x p k, in fact I learned about it
here.  It's then I started trying it, because in principle it is very
useful,
that I found out how broken it is for many other situations: ibuffer,
*gnus*,
and it's a shame we can't use 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.

You are attributing ill-intent to me from a moral high-ground you can't
really
claim.  I had no idea as to the authorship, so I can't have been engaging
in those
perfidious tactics.  But do I apologize for the word "abomination". If it
helps
I'll show you round to plenty such things written by myself in the past.

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.

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

That automation is just as buggy as C-x p k, and should be fixed, but
the only such automation we know is C-x p k.

> 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.
Not to mention it's just [insert acceptably derogatory word here] to protect
implementation details from misbehaving code that is under our control
and can just be fixed.

[-- Attachment #2: Type: text/html, Size: 3004 bytes --]