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: Fri, 28 Oct 2022 17:28:50 +0000 Message-ID: <87edur3lil.fsf@posteo.net> References: <87sfj8umwb.fsf@posteo.net> 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="39381"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Manuel Uberti , 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 Fri Oct 28 19:30:26 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 1ooTBZ-000A1j-MP for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Oct 2022 19:30:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooTBM-0004Ma-0Y; Fri, 28 Oct 2022 13:30:12 -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 1ooTBE-0004Hl-KX for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 13:30:05 -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 1ooTBC-0003CQ-Nq for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 13:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ooTBC-0007cM-Ck for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 13:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Oct 2022 17:30:02 +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.166697814829191 (code B ref 58839); Fri, 28 Oct 2022 17:30:02 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 17:29:08 +0000 Original-Received: from localhost ([127.0.0.1]:34200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooTAG-0007af-QV for submit@debbugs.gnu.org; Fri, 28 Oct 2022 13:29:08 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:60963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooTAB-0007a0-4k for 58839@debbugs.gnu.org; Fri, 28 Oct 2022 13:29:03 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1C277240027 for <58839@debbugs.gnu.org>; Fri, 28 Oct 2022 19:28:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666978133; bh=2Fc7mD3YcDQlwbpPR5bzCJSYdApFd+rcVmgZi5q4PYw=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=gXbzDwqz0kgWV5TbY9uPoUSN4h/Gtmj0rna/LgzE2JNZ5lymMsFh1gPlepArTTBEO nIhLKhclULvLb2G4y6UuO6rdRH6+uzYYIuASNX07oqieAuDeSBW5WwLP+ZU6AKLgoE f5EIqgwK/BwnC3JzjsJIQEeXO9tvf1zm+MVGz/krDDxCyW+2faJcDWtogHTwUWmZjo Ho3LFMdCEHoT2394+0UIYwfvfcuA/k3W9Z8UTuClGlHMnLeBS3ROZHMhD6Hv0rM2Mq yiveJOZAHxM4qMawYej8o+qmZDIuM2/THoglwbgOM1ra5XHV5CzRjkCkqJMybz1E7B yOps+voJ4NaCg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MzTzm1r66z6tmX; Fri, 28 Oct 2022 19:28:50 +0200 (CEST) In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Fri, 28 Oct 2022 18:17:18 +0100") 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:246439 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic > wrote: > >> When wanting to clean up behind a project I like to use C-x p k to get >> rid of everything I have opened related to it. If I was using Eglot and >> there is still an active LSP server running in the background, killing >> the project fails with these messages: > > Thanks Philip. This was discussed at > > https://github.com/joaotavora/eglot/discussions/822 > > Some more information is needed: > > 1. The error only happens when eglot-autoshutdown has been set to t by > the user. > > 2. When it has not been set to t, then the behavior is still not > correct, but the user may not notice it. > > 3. According to Manuel Uberti, the problem also happens with CIDER, a > Clojure IDE for Emacs. So it seems it is not exclusive to Eglot. > > The problem happens because `project-kill-buffers` uses project.el's > sense of a project buffer, and then endeavours to kill all such buffers. > > So far so good, but the determination of project buffers according > to `project-buffers` considers all buffers whose buffer-local default > directory starts with a given root of some project. > > This is subtly wrong because it also considers buffers whose name starts > with space and without buffer-file-names, so-called "hidden buffers" which > are deemed "uninteresting" to the user (according to the Elisp manual). > They commonly function as implementation details of other packages, such > as Eglot (and possibly CIDER). These buffers are not normally visible > to the user in M-x ibuffer, switch-to-buffer, etc. > > In Eglot's case, the buffer whose name is " EGLOT process..." is > created by eglot.el and then handed over to jsonrpc.el, which becomes > responsible for it. > > Killing this buffer from Lisp using `kill-buffer` is incorrect because > it contradicts Eglot's user preferences eglot-autoreconnect and > eglot-autoshutdown: > > 1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the > process and confuses the LSP shutdown logic, which is a polite > "teardown" conversation with the LSP server. This is Philip's error. > 2. If eglot-autoshutdown is nil but eglot-autoreconnect is non-nil (in > fact, these are the defaults), killing the buffer has the effect of > immediately restarting the connection, and thus re-creating the > buffer. The best that can happen is that nothing was achieved > and only time was wasted. > > The fact is that the buffer in question is an internal Eglot implementati= on > detail that other packages should stay clear of. > > In fact, I think that all hidden buffers can be considered thusly. > They're just like `--` symbols in obarray or in other symbol's plists: > they're visible to all Lisp packages but they are implementation details > that shouldn't be messed with except by the owner of such details. > > Dmitry tells me that there was some discussion where it was determined > that it's somehow useful in project-kill-buffers to also target buffers > that the > user isn't aware of. > > But I've not seen evidence of this usefulness. If there is indeed some, > I propose we come up with some convention so that it is possible for > packages to create buffers which are "definitely hidden and private and > not to me tinkered with". Such a convention could be starting the > buffer name with two spaces. > > Whatever the convention, currently I think that the patch after my > signature is the correct approach to fix this bug. > > Thanks, > Jo=C3=A3o > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index ac278edd40..4f542137a8 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -352,14 +352,18 @@ project--remote-file-names > (concat remote-id file)) > local-files)))) > > +(defun project--buffer-uninteresting-p (buf) > + (and (string-prefix-p " " (buffer-name buf)) (null (buffer-file-name > buf)))) > + > (cl-defgeneric project-buffers (project) > "Return the list of all live buffers that belong to PROJECT." > (let ((root (expand-file-name (file-name-as-directory (project-root > project)))) > bufs) > (dolist (buf (buffer-list)) > - (when (string-prefix-p root (expand-file-name > - (buffer-local-value 'default-directory > buf))) > - (push buf bufs))) > + (unless (project--buffer-uninteresting-p buf) > + (when (string-prefix-p root (expand-file-name > + (buffer-local-value > 'default-directory buf))) > + (push buf bufs)))) > (nreverse bufs))) > > (defgroup project-vc nil > @@ -680,11 +684,12 @@ project-buffers > dd > bufs) > (dolist (buf (buffer-list)) > - (setq dd (expand-file-name (buffer-local-value 'default-directory > buf))) > - (when (and (string-prefix-p root dd) > - (not (cl-find-if (lambda (module) (string-prefix-p modu= le > dd)) > - modules))) > - (push buf bufs))) > + (unless (project--buffer-uninteresting-p buf) > + (setq dd (expand-file-name (buffer-local-value 'default-directory > buf))) > + (when (and (string-prefix-p root dd) > + (not (cl-find-if (lambda (module) (string-prefix-p > module dd)) > + modules))) > + (push buf bufs)))) > (nreverse bufs))) I still don't agree that this is the right interpretation of the issue or solution, but wouldn't it be better to add this to `project-kill-buffer-conditions'? The solution I would prefer is if project.el would define a sort of project-kill-hook, that Eglot would modify and make sure that `eglot-shutdown' is invoked before any buffer is killed.