From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Date: Wed, 02 Nov 2022 14:42:59 +0000 Message-ID: <87r0ylh0y4.fsf@posteo.net> References: <87sfj8umwb.fsf@posteo.net> <87v8o3wgq1.fsf@gmail.com> <87ilk2x1si.fsf@gmail.com> <871qqq7l9p.fsf@posteo.net> <87eduqwekz.fsf@gmail.com> <87wn8invbx.fsf@posteo.net> <877d0iw8iq.fsf@gmail.com> <837d0hhlke.fsf@gnu.org> <46ff0065-5645-ef1e-2621-242fb6a73f98@yandex.ru> <87v8o0uxn5.fsf@gmail.com> <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> <87edunvhf2.fsf@gmail.com> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@yandex.ru> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@yandex.ru> <87a659u7vo.fsf@gmail.com> <8735b1bvnz.fsf@posteo.net> <87mt99spsk.fsf@gmail.com> <87r0ylafdl.fsf@posteo.net> <87cza5sbfx.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32830"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 58839@debbugs.gnu.org, Dmitry Gutov To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 15:44:20 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oqEya-0008KZ-0D for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 15:44:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqEyK-0001vc-E0; Wed, 02 Nov 2022 10:44:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqEyI-0001v6-Jt for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 10:44:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oqEyI-0004WL-CW for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 10:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqEyH-0006kj-Uc for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 10:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 14:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58839 X-GNU-PR-Package: emacs Original-Received: via spool by 58839-submit@debbugs.gnu.org id=B58839.166740019125888 (code B ref 58839); Wed, 02 Nov 2022 14:44:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 14:43:11 +0000 Original-Received: from localhost ([127.0.0.1]:46929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqExS-0006jU-W9 for submit@debbugs.gnu.org; Wed, 02 Nov 2022 10:43:11 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:39709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqExR-0006jH-3k for 58839@debbugs.gnu.org; Wed, 02 Nov 2022 10:43:09 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 92669240027 for <58839@debbugs.gnu.org>; Wed, 2 Nov 2022 15:43:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667400183; bh=3roSJmNTpjwRyTG2KuL5vChIpLyzYe2+QuXqaftY3vU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=p+RwVeJRveO/CbGP2Qb8R5iQa6e6IX+xuSoCE+LY8txr6E7EroF7NaUnGd1JBuK48 B6ecVO5jbSC7yEOZKKD9sqqQlhkaApHrhDYHBCAcgkMbws7S/NfaVego5dAMTb2oMz KXa4yFyesesZyEODPzScliq2piX2YGYv7eVCcIvD6K2fRQQ+LSt1c53oD2MZB8MD6U eGpxuFz8QlixdxEV9JHLsfSUz/7i8tWtbFAend3eMiBxTKm2135WrZbz7Cz6usk70W 5AEsyN2c0Gnk6OGG9w+yUy47W6+OAuGUv5ERCm36rso8RDaPnxb7yi3/0XDWhqdXzD UPlcaVTyb1/7w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2V463CxNz9rxK; Wed, 2 Nov 2022 15:42:59 +0100 (CET) In-Reply-To: <87cza5sbfx.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 14:00:50 +0000") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246873 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Philip Kaludercic writes: > >> Jo=C3=A3o T=C3=A1vora writes: >> >>> Philip Kaludercic writes: >>> >>>>> Not sure. This started has a report of hidden buffer being incorrect= ly >>>>> killed by project.el.=20=20 >>>> >>>> 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.=20=20 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).=20=20 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 =E2=80=98list-buffers=E2= =80=99 and =E2=80=98buffer-menu=E2=80=99 commands don=E2=80=99t 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.