From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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 21:38:04 +0100 Message-ID: <87eduqwekz.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28350"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Manuel Uberti , 58839@debbugs.gnu.org, Dmitry Gutov To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 29 22:38:22 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 1oosaz-0007AQ-5Q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 22:38:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oosah-0006yx-JN; Sat, 29 Oct 2022 16:38:03 -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 1oosag-0006yp-Cr for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 16:38: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 1oosag-0000lS-1R for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 16:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oosaf-0008MM-SN for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 16:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 20:38: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.166707582532063 (code B ref 58839); Sat, 29 Oct 2022 20:38:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 20:37:05 +0000 Original-Received: from localhost ([127.0.0.1]:36772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oosZk-0008L3-KA for submit@debbugs.gnu.org; Sat, 29 Oct 2022 16:37:05 -0400 Original-Received: from mail-wr1-f50.google.com ([209.85.221.50]:45941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oosZh-0008KR-Rk for 58839@debbugs.gnu.org; Sat, 29 Oct 2022 16:37:02 -0400 Original-Received: by mail-wr1-f50.google.com with SMTP id y16so10782466wrt.12 for <58839@debbugs.gnu.org>; Sat, 29 Oct 2022 13:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=S0ouhzMDaqav1T/5iCcQZG2iVhgyQDI0e+eQU6vfY9E=; b=qNLd4EcNO40+O9AYVps0Plyp88JHPRIt/zmoJCBXWfrmf1AddzGykFwwtjJjXGewDk 212BMldZ/3/W/YQ4sfamBq1RUq+l3cX4Jaa4hAvkfa86YqBS9Tj6BfOVh7BIs5CyWOb+ AB2zXR7uEg5BhW1wvCk9vQEnawLaDm8DdRmF9vHShfWrdW46cJlrcznpdDhh1NsrbNCy O447yepAKQXSnVbhY5N+8CfO2ek3xFwNh7Wx3bvXrkHOJ/8DI57p8mO0q18dKZhIb+rs 1iCYiTxgcfggJPxMISwNrjyhb9xO2ySQHDRf/TLO+V7I9SyjGtEJbFMX9ifYfAfZFkS1 48oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=S0ouhzMDaqav1T/5iCcQZG2iVhgyQDI0e+eQU6vfY9E=; b=FtU6RFiDXlARz/OzC9SYs43MCi6klMMkGlMrtVm9NkkNW0lfQ6hpINhvOJrCWHhSLr wcgE2rI4xpGa1ghYSFcq45077fjO0iheC3KEaXcHjePk/RkHJVk4MhVMkELWyeftUn4W TUhHb4nsjyjE01siM+yBDwMM9N9p04Sxe8+axOrZckiOW6sZQ5pNvWum14sp4H2vprI2 /otA0hKszgiLG2TimzhTx7m5LuYY0hVO9T3V+/h2JgE77bLSkKnyyRZ+lN9uduI38pO8 bxn1gSfRTBpIcHLFUzajlFZB8aRh0+6j4/Mr4/cbCrnjFhb+1Ebaey2yvOqwEwo8WUIH QSzw== X-Gm-Message-State: ACrzQf0vBp2xPtJgu9SlcUNdMaExOEnZQVk5i2ftuePxNNYzDmyUSsTC pUv9moZfXtf1VSPK12OW/ALV5p9hgDg= X-Google-Smtp-Source: AMsMyM4968E4aLqNhVg/dPP61yor3/c0YSPlmXhACQh813mOGgCX39DrRH7W0/imzue6gyQozzKtYQ== X-Received: by 2002:adf:e385:0:b0:236:91a6:bd1b with SMTP id e5-20020adfe385000000b0023691a6bd1bmr3230197wrm.278.1667075815494; Sat, 29 Oct 2022 13:36:55 -0700 (PDT) Original-Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89]) by smtp.gmail.com with ESMTPSA id bj29-20020a0560001e1d00b002366b241cf3sm2352665wrb.35.2022.10.29.13.36.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Oct 2022 13:36:54 -0700 (PDT) In-Reply-To: <871qqq7l9p.fsf@posteo.net> (Philip Kaludercic's message of "Sat, 29 Oct 2022 14:32:50 +0000") 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:246572 Archived-At: 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. >> 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. >> 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. >> 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. > 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))) +(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" 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.