From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 04:09:13 +0300 Message-ID: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@yandex.ru> References: <87sfj8umwb.fsf@posteo.net> <87edur3lil.fsf@posteo.net> <87a65f3j40.fsf@posteo.net> <213f3549-de4e-25a7-5e27-d13893e557bc@yandex.ru> <87zgdfwkle.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34973"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: Philip Kaludercic , Manuel Uberti , 58839@debbugs.gnu.org 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 Sat Oct 29 03:10: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 1ooaMe-0008xJ-HR for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 03:10:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooaMS-0005wd-3i; Fri, 28 Oct 2022 21:10:08 -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 1ooaMQ-0005wG-5Y for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 21:10: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 1ooaMM-0003Yi-Fm for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 21:10:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ooaMM-0000T0-1i for bug-gnu-emacs@gnu.org; Fri, 28 Oct 2022 21:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 01:10: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.16670057631740 (code B ref 58839); Sat, 29 Oct 2022 01:10:02 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 01:09:23 +0000 Original-Received: from localhost ([127.0.0.1]:34585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooaLi-0000S0-Tt for submit@debbugs.gnu.org; Fri, 28 Oct 2022 21:09:23 -0400 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:33352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooaLh-0000Rm-2q for 58839@debbugs.gnu.org; Fri, 28 Oct 2022 21:09:22 -0400 Original-Received: by mail-wm1-f48.google.com with SMTP id 14-20020a05600c228e00b003cf4eaef74eso4140489wmf.0 for <58839@debbugs.gnu.org>; Fri, 28 Oct 2022 18:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=ERtSdsGFWugoH5FE3ZTapyIsB7jLM0KLRY/XjIek4DM=; b=CbZlJUA1NmyCgmo+0updqrf56xr1CuUM3ZbpkharKgOY65mgYDoqV/4NJawcOL1aae nS/FOMwYHkRH/U5pWvtWFhV2/793U3UkqD6bLOzM32+Y6+WOrgArNqXwMPXiwHPN8AUw 0JydatlZsWRugXLPhqrdL9LjZC4MxSdpx3hUNany+wTLmRzgKTI4xrmJ4mkDWxmO1lMB NUGdER76YjXPMqI3K0Jn5ZrIRM3DF6fUWkRftxM8ewwe8TgdxGll0+7H5TAw8zGHBZpS 9IuZWgwcs+2Krb4lcHu1hAxRGUk/a5RFXVLe2GF4kuB0XOv0HxixyO7aH7CSrroYTnIa Li9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ERtSdsGFWugoH5FE3ZTapyIsB7jLM0KLRY/XjIek4DM=; b=LuvzAWuDTqUh22MGRAoaB1W5JHyREc7gCPT+DuFNiR97e/THnR/r5BsLMqeqNUPeF7 uTAYfq239CEuUWgNHAEwmXLyJf7vvHjPq0/uEWNDa8cPoLNGU8ZrBYkhSovmqM4zhurU EI7sMVNvncS8veUusqxLh3ZVlUPNMWQXumT01WvG9Jq3ou/p9x+Lx5FFgdtTxWX6M08T GkdDGkTMiJbe9N0kRw6apAiszbd4yMehuIfN2k9iihXjXm1TfdvdSG49Ys4cCfMopKCH caqK7QenZBJ/0ggsXAghqZXoM4l2Pb0r3AJfQM4AXO//xTuqD9HhLoJiv7Vq+OTTaz9m HV7w== X-Gm-Message-State: ACrzQf2rp2TSLP82mPwewRAayHud3hVa8g8o5ZvmupVVFLH0uEPbFqBe +SjkZqfpSTX9/3XWR+QlSo8= X-Google-Smtp-Source: AMsMyM5/EuG7vt/rIqut80oPPkyrmk32w8k0zLl+SxbmBzLkB4DNuQ0l6DKMrlfLf8UhkSlyrW+yWA== X-Received: by 2002:a05:600c:2196:b0:3cf:4de3:163c with SMTP id e22-20020a05600c219600b003cf4de3163cmr9991728wme.122.1667005754907; Fri, 28 Oct 2022 18:09:14 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id az29-20020a05600c601d00b003cdf141f363sm156077wmb.11.2022.10.28.18.09.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 18:09:14 -0700 (PDT) Content-Language: en-US In-Reply-To: <87zgdfwkle.fsf@gmail.com> 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:246471 Archived-At: On 29.10.2022 03:15, João Távora wrote: > 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. Sorry, I don't have Eglot checked out, or the time to test out the patch. > 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? I suppose. But the current criterion depends on the value of default-directory, and that makes it a match. > 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. I'm not sure. Intuitively, I'd say that this buffer belongs to the project because it "services" the project. But if it were to work for several projects at the same time, I suppose I could say it doesn't belong to any particular one. > 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. *scratch* is not that special - you can create similar buffers at will. So there are two ways of looking at that question. One can create a "scratch" for a project, and it will be part of that project. If "~" (the usual value of default-directory in the original *scratch*) belongs to a project, then *scratch* also does. > * 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. We could make an exception for that too. > 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. It's not much better than adding a function to kill-buffer-query-functions that returns nil. And/or behaves accordingly to eglot-autoshutdown. > 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. I'm unable to find that message.