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: Sat, 29 Oct 2022 22:01:06 +0000 Message-ID: <87wn8invbx.fsf@posteo.net> References: <87sfj8umwb.fsf@posteo.net> <87edur3lil.fsf@posteo.net> <87a65f3j40.fsf@posteo.net> <213f3549-de4e-25a7-5e27-d13893e557bc@yandex.ru> <87zgdfwkle.fsf@gmail.com> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@yandex.ru> <87v8o3wgq1.fsf@gmail.com> <87ilk2x1si.fsf@gmail.com> <871qqq7l9p.fsf@posteo.net> <87eduqwekz.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="17938"; 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 Sun Oct 30 00:02:19 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 1ootuE-0004Sz-Jw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Oct 2022 00:02:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ootu7-0007Jr-UV; Sat, 29 Oct 2022 18:02:11 -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 1oottz-0007Ff-0z for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 18:02:06 -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 1ootty-0001k4-EL for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 18:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ootty-00027W-1F for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 18:02: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: Sat, 29 Oct 2022 22:02: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.16670808798099 (code B ref 58839); Sat, 29 Oct 2022 22:02:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 22:01:19 +0000 Original-Received: from localhost ([127.0.0.1]:36838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oottH-00026Z-0a for submit@debbugs.gnu.org; Sat, 29 Oct 2022 18:01:19 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:59873) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oottF-00026L-AQ for 58839@debbugs.gnu.org; Sat, 29 Oct 2022 18:01:18 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6976A240107 for <58839@debbugs.gnu.org>; Sun, 30 Oct 2022 00:01:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667080871; bh=nip3pJXsfQZt8en4sN8DUdAH/1hERr5BIur8uZXdTG4=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Wk2VWnj+pbmxa1y/Bi/OApj9Ac6c0NGSxvVGKbacxh6sZAYjXDxb3wvD7L0pvCMGF 0JzqTeDrQx58teJyxV5d08LhiaWsYsCGXtQd2Bw5JvmdlyyNSgjwJ8TKf83WWQPpKT yeGQyZjGwbpxSR+0O+Ghx5+OsOEwJ5WVg1gdaJgcJXsXbZDWVyU07PYPLRxb9uRN7I II/R9U4Bx6RSPpPa7Q1ZIFcB86WR7JfvjkCFg82xBYGQKS7JMQTbd80+L0+zMzEpPS K6XGNxfWBcC6+9fC/Qt7IUlOHGUQKk1cnvJU1USLKGh+ix3+VvyCuKv+TP1FooskxG owdz+FLJqm6Tg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N0CzS08Gkz6tpL; Sun, 30 Oct 2022 00:01:06 +0200 (CEST) In-Reply-To: <87eduqwekz.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 29 Oct 2022 21:38:04 +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:246575 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Philip Kaludercic writes: > >>> bytes, but it shouldn't rely on their values and certainly can't free() >>> what it didn't malloc(). >> But to extend this metaphor, if I kill a programm that allocated malloc, >> I would expect that memory to be cleaned up. > > Yes, but to kill a process you have to own it. project.el is not the > owner (not even a co-owner) of Eglot LSP internal buffers, and so it > can't kill them. What would be a co-owner? My view is that project.el is a manager of buffers, but that isn't relevant anymore. >>> I think the command is pretty useful. But perhaps, I'm just guessing >>> here, Philip is focusing too much it as if it were the only sanctioned >>> way for Emacs users to stop working on a given set of files in a >>> programming project and clean up. >> Of course it isn't, it is just my prefered way and Eglot breaks it. > > I don't think we should play the who-broke-what game. It doesn't help, > and if we decided to look up the dates of introduction of your > project-kill-buffers way and eglot's process management, we might reach > a different conclusion. I really just meant "break" as in works until Eglot is enabled, and nothing more than that. >>> Neither do I. But when I M-x cd to other places, project.el thinks that >>> scratch belongs to that project. It doesn't, I keep stuff of various >>> projects in it. >> >> I agree, this is bad, but that can easily be solved by adding >> `lisp-interaction-mode' to the list of major modes that are not >> killed. > > Also *ielm*, the global Elisp repl created by M-x ielm. has the same > problem. And *Completions*. I'm quite sure that *sly-scratch* in the > SLY CL IDE would also be targeted. And the CIDER Clojure IDE, as > someone has already reported. And probably many more. This blanket > default-directory heuristic is practical in some common cases but flawed > in many others. Project.el uses the same condition format like `buffer-match-p', which is quite flexible. Maybe all earmuffed buffers should be spared ("\\`\\*.+\\*\\'"), but in my experience that can be too lenient. >>> Just commit the original tested patch I gave you that exempts hidden >>> buffers without buffer-file-name from project-buffers. Philip's command >>> will keep working perfectly and we can close this bug. >> >> So if I understand correctly, with `eglot-autoshutdown' enabled as soon >> as all the buffers have been killed, the server will also shut down, >> right? > > Yes! This is exactly what the docstring says: > > eglot-autoshutdown is a variable defined in `eglot.el'. > > If non-nil, shut down server after killing last managed buffer. Ok, great. >> Regarding the patch itself, I think it would be better to use >> `project-kill-buffer-conditions', so that if a project.el backend >> defines a new implementation for `project-buffers', the issue doesn't >> pop up again. > > Your concern is quite valid. Fortunately, CLOS generic functions have > us covered. This is even simpler than the first patch: > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index ac278edd40..f8190eb1fc 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -362,6 +362,13 @@ project-buffers > (push buf bufs))) > (nreverse bufs))) >=20=20 > +(cl-defmethod project-buffers :around (_project) > + "Ensure hidden/private buffers do not belong to PROJECT." > + (cl-remove-if-not (lambda (b) > + (and (string-prefix-p " " (buffer-name b)) > + (not (buffer-file-name b)))) > + (cl-call-next-method))) > + > (defgroup project-vc nil > "Project implementation based on the VC package." > :version "25.1" I have to still admit that I am uncertain if the general ignoring of all hidden buffers is justified. I have certainly used hidden buffers frequently enough but never assumed that they were outside of anyone's control. They are just regular buffers with a special kind of name after all. We ought to be able to define a cleaner way of clarifying what buffers can and cannot belong to projects. Personally I think a buffer-local variable/predicate would be a better approach. > Note this still leaves the *scratch* and *ielm* and other things > uncovered. It addresses this specific bug and most importantly doesn't > blow up in the users.