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 01:15:57 +0100 Message-ID: <87zgdfwkle.fsf@gmail.com> References: <87sfj8umwb.fsf@posteo.net> <87edur3lil.fsf@posteo.net> <87a65f3j40.fsf@posteo.net> <213f3549-de4e-25a7-5e27-d13893e557bc@yandex.ru> 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="28236"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , 58839@debbugs.gnu.org, Manuel Uberti To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 29 02:16:29 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 1ooZWX-0007By-Ji for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 02:16:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooZWA-0003Dy-6G; Fri, 28 Oct 2022 20:16:06 -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 1ooZW6-0003DZ-VD for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 20:16:03 -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 1ooZW6-00050E-9i for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 20:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ooZW5-0007WL-UN for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 20:16: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 00:16: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.166700250128808 (code B ref 58839); Sat, 29 Oct 2022 00:16:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 00:15:01 +0000 Original-Received: from localhost ([127.0.0.1]:34523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooZV6-0007UK-Qx for submit@debbugs.gnu.org; Fri, 28 Oct 2022 20:15:01 -0400 Original-Received: from mail-wm1-f54.google.com ([209.85.128.54]:33493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooZV1-0007Tx-0Z for 58839@debbugs.gnu.org; Fri, 28 Oct 2022 20:14:59 -0400 Original-Received: by mail-wm1-f54.google.com with SMTP id 14-20020a05600c228e00b003cf4eaef74eso4119896wmf.0 for <58839@debbugs.gnu.org>; Fri, 28 Oct 2022 17:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=HMjLyUQUBWPWXEFvLdG+3+qjKdrBmYkWm4ht3LFRSGk=; b=bow9NPHVhq+2xCikKWo9PKl5e3Ca1u7susqaXZZt/MblT1Dw4uCfmSt28XCriWYM1N aMK8bveqq97Ea1dIN4YrlV9aeVTOpyNJBm5H+0m3DtF0Vru+uyrd+KG8L8Ddp0RHfzbj 49PdpCIr2asKkRbr5zQ4eAO/0bYt2FRlg+b5r04BuCkV+675/+5P0UHXurW4sGFbJxU1 94OQdlwbfooGzM1/3rVmEuL9Jo5pFGEaOwWlpvR1+65yvQbsU4hX8ax768nkxI3LfTQc T3nUEVqYT/aRKVyds0P5M99h8K3iiBHy7l48xjxmTSI0PYZf/2E/xPOft/Pk1PDnCySB pwXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=HMjLyUQUBWPWXEFvLdG+3+qjKdrBmYkWm4ht3LFRSGk=; b=1caPViiGu8mVZhlhjJQxOfYQbJC7rQeYiFskZtZz7RRXxU9WP9ss1QEK1f9becYAZ0 nm1GNEdjEEaAMoamX8vRFSrSgaXjZOhgBq8fWm+yHukHD2NjdDsbkJZOHQ0y9GAqMD1G IukwPWxyPy77UXEq2r1i/u7i2/0rH352/QNPMv633ljg2uEmfKmMWNGI0QVjmgTvN8Kf 2pYgEsbrsvQ/49mfWrTgb6c6f+RW8CXYZu5UGqiEUn7dUmB0wlvEOSxgs7uHk9NgsUB+ yhbQ5Rl2sIjhDjWgY0Etc1M6ji0+HPtVzLxFeLfHlGyxxpT951j9dc4uHwgzLPSe/kM+ i1iw== X-Gm-Message-State: ACrzQf0GODL6tCIGQUOSPqbWe2sPV/mTy+HmJpTmQNm8Vzuh9JEK4Gjx K5Rq17GhH0/CKbO0BzkBI4Ww0stywH4= X-Google-Smtp-Source: AMsMyM5duHoYlo9KHiORI+4lg8bppNrVl64uKzg1x9X8qPfUG0OExG++13HlI9OU6YW/lZKViNy4WA== X-Received: by 2002:a05:600c:600e:b0:3c6:fc59:5eda with SMTP id az14-20020a05600c600e00b003c6fc595edamr1020521wmb.30.1667002488607; Fri, 28 Oct 2022 17:14:48 -0700 (PDT) Original-Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89]) by smtp.gmail.com with ESMTPSA id s12-20020a5d6a8c000000b002364c77bcacsm70450wru.38.2022.10.28.17.14.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 17:14:48 -0700 (PDT) In-Reply-To: <213f3549-de4e-25a7-5e27-d13893e557bc@yandex.ru> (Dmitry Gutov's message of "Fri, 28 Oct 2022 21:40:58 +0300") 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:246467 Archived-At: Dmitry Gutov writes: > (defun eglot-before-kill-special () > (eglot-shutdown) > t) > > ;; somewhere inside that special buffer's setup: > (add-hook 'kill-buffer-query-functions #'eglot-before-kill-special nil t) > > Or use kill-buffer-hook, no need to watch the return value then. Thanks, but this is simply wrong. Besides missing a required argument, it doesn't respect the preference of eglot-autoshutdown: I explained that in the second message of this thread replying to Philip. I also explained in that message that Eglot doesn't "own" the process buffer, jsonrpc.el does. Clients of jsonrpc.el don't even know there's a process buffer, they only own a handle to a jsonrpc "connection", which may or may not use buffers underneath. So your "somewhere inside..." is a big problem. > In either case, it will also cover the scenario of the user killing > the background buffer some other way. The "background buffer" is hidden. Users don't see it unless they go considerably out of their way. Even M-x project-switch-to-buffer somehow doesn't list it. Let me ask you this: can you conceive to that some buffers in Emacs's buffer list simply don't belong to _any_ project? If you agree that there are such cases, then it should become clear that the buffer in question must be at the top of that list. There are more hints that the concept of "buffer belonging to a project" was not fully thought through, even in cases unrelated to this bug report. * Take the *scratch* buffer. It has a default-directory. Does this also make *scratch* belong to a project? It doesn't make any sense to me that it would. Yet it is caught by project-buffers. * project-buffers also catches the one-time *Completions* buffers, the kind produced by hitting TAB after C-x p b. If you type C-x p b again, it quite comically offers the stale *Completions* buffer as a candidate to switch to. But back to *scratch*. Somehow *scratch* is not killed by M-x project-kill-buffers. I think it's because it doesn't have a buffer-file-name. But then neither does the Eglot/Jsonrpc's "background buffers"! It seems it is being targeted merely because it uses fundamental-mode, a most reasonable mode to use for exchanging messages via standard streams. I guess this means that the hack below is enough to fix the issue, but it is also decidedly silly. So please consider fixing this in project.el. As Manuel pointed out, the venerable ibuffer.el's ibuffer-kill-filter-group also kills project buffers and handles this whole thing very well. We should just take a hint from it. Jo=C3=A3o diff --git a/lisp/jsonrpc.el b/lisp/jsonrpc.el index 90833e1c1d..2914d380e9 100644 --- a/lisp/jsonrpc.el +++ b/lisp/jsonrpc.el @@ -365,6 +365,9 @@ jsonrpc-process-connection :ON-SHUTDOWN (optional), a function of one argument, the connection object, called when the process dies.") =20 +(define-derived-mode jsonrpc--fundamental-mode fundamental-mode "" + "Make project.el's stay out of our internal buffers.") + (cl-defmethod initialize-instance ((conn jsonrpc-process-connection) slots) (cl-call-next-method) (cl-destructuring-bind (&key ((:process proc)) name &allow-other-keys) s= lots @@ -377,6 +380,7 @@ initialize-instance ;; (but maybe not a slot). (let ((calling-buffer (current-buffer))) (with-current-buffer (get-buffer-create (format "*%s stderr*" name)) + (jsonrpc--fundamental-mode) (let ((inhibit-read-only t) (hidden-name (concat " " (buffer-name)))) (erase-buffer) @@ -411,6 +415,7 @@ initialize-instance (set-process-filter proc #'jsonrpc--process-filter) (set-process-sentinel proc #'jsonrpc--process-sentinel) (with-current-buffer (process-buffer proc) + (jsonrpc--fundamental-mode) (buffer-disable-undo) (set-marker (process-mark proc) (point-min)) (let ((inhibit-read-only t))