GNU bug report logs - #58839
29.0.50; project-kill-buffer fails when Eglot is running

Previous Next

Full log

Message #227 received at 58839 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, manuel.uberti <at> inventati.org,
 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
 fails when Eglot is running
Date: Wed, 02 Nov 2022 09:13:10 +0000

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

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>>> 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'.
>
> No.  It couldn't.  The error is there to show you among other things
> that the LSP connection isn't being shut down correctly, which is not
> something to paper over.  And even if you did paper over the error, you
> would break eglot-autoshutdown.  I've explained that at least 3 times
> already in the beginning of this discussion.

That was not my concern, my concern was that project-kill-buffer broke.
I continue to not see a reason why project.el should be considered
broken because of this, and not jsonrpc/eglot.

To be fair, I am not as familiar with LSP as you are, so there might be
a technical reason why this is the case, but without something like
that, you appear to be privileging an arbitrary perspective, supposedly
because you are the maintainer of these packages.

This is probably best solved by reading code.  Can you point me to a few
functions/section/etc. that would help me clarify the situation.

>>> 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.
>
> I just said that becasue you at one point did suggested the
> opt-in approach 
>
>   I have to admit that I am more and more inclined to make the list a
>   opt-in thing, where  we explicitly mark those major modes that are tied
>   to a project.

The key word here is "more and more inclined".

> But of course it's OK to change one's mind back and forth.

I haven't made up my mind, I am just trying to understand all
perspectives, and get a better overview over the issue.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.