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

[Philip Kaludercic <philipk@posteo.net>]

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> João Távora <joaotavora@gmail.com> writes:
>>
>>> Philip Kaludercic <philipk@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.
>
> It was always broken since the way it was created.  Eglot's precedes it,
> I've also explained this.  

This is not an argument.

>                            You can't kill a internal hidden buffer just
> because you can see it anymore than you unintern some "--" symbol in
> obarray simply because you can see it and don't like its inelegant name,
> or you think it's taking too much RAM.  I can't really explain this any
> other way.

The equivalence is not given, more so because there is no package that
manages symbols the way that project.el manages buffers.  If this is
all, your argument, or rather statement, is simply not convincing, no
matter how often it is reiterated. *

>> 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.
>> I haven't made up my mind, I am just trying to understand all
>> perspectives, and get a better overview over the issue.
>
> OK, one last time.  First, the above principle of encapsulation has
> nothing to do with LSP or Eglot or Jsonrpc.

Again, it is not given that this applies to buffers.  Robust code should
be able to handle a missing resource or prevent the resource from being
revoked.  This is not possible with buffers, so this is a design fault
with Eglot or Jsonprc. *

> Specifically in Eglot, as I already explained, eglot.el and jsonrpc.el
> colaborate so that jsonrpc.el holds a network process to communicate
> with the LSP server.  It uses a buffer for more convenient and efficient
> parsing of messages.  That buffer is out of bounds for Eglot (and anyone
> else).  

Can I `switch-to-buffer' into it, can I `kill-buffer' it?  Yes?  So it
is not out of bounds, and a mistake was made in the design by assuming
this is the case. *

E.g. why does the buffer have a default directory?

>         Eglot doesn't know or care that a buffer is being used, it only
> actuate on the handle using operations of jsonrpc.el's API.  According
> to user options, Eglot provides controlled shutdown and reconnection
> using these operations.

OK, these appear as convince options that can be used, but don't prevent
me from killing any buffers. *

> All of this has worked for a long time and predates project.el's buffer
> collection/killing/switching logic.

Again, this is not an argument, just a statement of fact that doesn't
imply anything definitive.  From the same statement I can also infer
that jsonrpc/Eglot had an undetected bug that was exposed by project.el.
You are committing an informal logical fallacy by assuming some kind of
temporal order in the attribution of mistakes. *

> If you or some Lisp package finds and destroys the hidden implementation
> detail, all the above is broken.  Therefore packages like project.el
> that do it are buggy in that regard.

This is a "If it can be destroyed by the truth, it deserves to be
destroyed"-kind of thing.  Double-dash symbols are "private" by
convention, but that might change in the future.  Hidden buffers are
just not displayed, as said in the manual (found via the index):

    Buffers that are ephemeral and generally uninteresting to the user
    have names starting with a space, so that the ‘list-buffers’ and
    ‘buffer-menu’ commands don’t mention them (but if such a buffer visits a
    file, it *is* mentioned).  A name starting with space also initially
    disables recording undo information; see *note Undo::.

The keywords being "ephemeral and generally uninteresting", not "private
and off-limits" This is not the same kind of thing like with a symbol
that was generated using `make-symbol', where you are guaranteed nobody
can access it without being passed the symbol directly or via some dirty
hacks.  And just so it is clear, using `buffer-list' is not a dirty
hack. *

If you need private buffers, you either need to argue that the
convention be clarified in the reference manual or have these
implemented in such a way (e.g. by passing a flag to
`get-buffer-create') nobody can access a private buffer without being
passed the buffer object or via some dirty hacks.  And just so it is
clear, using `buffer-list' is not a dirty hack.

  * These are all "Strong Opinions, Weakly Held", I really don't care
    about it too much.  What I don't like about this discussion is the
    tone you take in postulating the mistake was made somewhere else and
    that is that.  This is arrogant, unkind and non-constructive
    behaviour.  If necessary I am ready to discuss this off-list and
    resolve any issues.  I am inherently non-confrontation and dislike
    the fact that I have to even clarify this.  My top priority is
    always to find common grounds.

    I am almost never frustrated by discussions on the Emacs development
    mailing list or in bug reports.  The tone is at best productive, at
    worst lethargic.  This thread is an exception, which is very sad to
    see.  I implore you once more to consider the GNU Kind Communication
    Guidelines and try to foster a productive and positive atmosphere.