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 14:27:31 +0300 Message-ID: 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> 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="39004"; 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 , 58839@debbugs.gnu.org, Manuel Uberti 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 13:28:11 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 1ook0Z-0009z4-AD for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 13:28:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ook0R-00076f-KW; Sat, 29 Oct 2022 07:28: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 1ook0Q-00076Y-GO for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 07:28: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 1ook0Q-00074j-7a for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 07:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ook0P-0003yv-OZ for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 07:28:01 -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 11:28: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.166704286315280 (code B ref 58839); Sat, 29 Oct 2022 11:28:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:27:43 +0000 Original-Received: from localhost ([127.0.0.1]:35043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ook06-0003yN-Pe for submit@debbugs.gnu.org; Sat, 29 Oct 2022 07:27:43 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:54833) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ook03-0003y5-7A for 58839@debbugs.gnu.org; Sat, 29 Oct 2022 07:27:41 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id t1so877760wmi.4 for <58839@debbugs.gnu.org>; Sat, 29 Oct 2022 04:27:39 -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=u5YgxzYMcnD81UP7fVRKXtSlFvPGLUkUz6hTa6UL/2A=; b=MuHuvpsNbJdE2oG8qnup87ioYOmFpLCWVd43OiTwG4ZCNIx+DqbJ5FHNYochHkm+pw iZjgWC2AOAGERGGxuVOeQPis4dIgabT32Oqr2lFG0U9SKE5AuxPAAfCvynZtSg9w5G6K kbtY2ES5hXTVoTRg0AKFqYMD0ps8mFr0nRA0Rs2TfAI7kd95Re+6Ml8VI7qbr9Gun/pr cXGYU+Zh1oDt362uwpruFsodV7odSaSGAM4bp45z1UOEqKpWgATLqGqbhCMfjQQtiXg5 ILFLh2ZwiwVY1vgVUdNpERSguiqqLLAsT7+T3odJpCIvSfis6LtUFww7E58f6DsRIplU rdjQ== 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=u5YgxzYMcnD81UP7fVRKXtSlFvPGLUkUz6hTa6UL/2A=; b=K3DiTpj8dDcYiKbTfyprAqUHBFVZYBo8tbbhbpquwqg6ypXQZq/NQAh6UH0JmYJ7ln GH5HAqEwoOkkioGbDxt538Pt3UDy7xvpwKp5JjNXsYynWSmmr/zTXOWo34X5X7xnvfiw 54Z8hfKDtb+PdGmZWDYy9rc8ST+y2fa8cG47g4SRFdnlbbjr4uHIaHUQfSbl0Cbi8Jzk dqHvAwfuyKZf8BDIZMflbxZb3saYWtvHSM1JjjbfYS1ctB1GumqSXySNFbWBLzHHibFD Mz8HKQr5oJ9FdwfmhuhxgjTCv4Spo4D2oodn+ma88Z4MwaNtjfdouOfgTKZTquwfZUJg 9KBg== X-Gm-Message-State: ACrzQf3fwIivgOBjrHxR/d+pwlf8g577vThhvlP/pInYyOudCPFaR1qf RnJbDpWFyliKm8aswE3DZxU= X-Google-Smtp-Source: AMsMyM5DB+tUllkZzddfguEyP+2zIUBpaQmmlbgSv2LYSK3HbrWDyMdkVDhlQw77GF114VNRvPmwnA== X-Received: by 2002:a05:600c:42c9:b0:3cf:69d4:72d9 with SMTP id j9-20020a05600c42c900b003cf69d472d9mr305765wme.93.1667042853255; Sat, 29 Oct 2022 04:27:33 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id ck1-20020a5d5e81000000b002366553eca7sm1316589wrb.83.2022.10.29.04.27.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Oct 2022 04:27:32 -0700 (PDT) Content-Language: en-US In-Reply-To: <87v8o3wgq1.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:246514 Archived-At: On 29.10.2022 04:39, João Távora wrote: > If you missed it, Eglot has been merged in lisp/progmodes/eglot.el. > There's not much point in testing that your patch: I can tell you right > away it doesn't work. I was thinking that somebody motivated could easily update it to be functional. >> I suppose. But the current criterion depends on the value of >> default-directory, and that makes it a match. > > This criterion is wrong. It makes mistakes. But a criterion that is > "default-directory and is not hidden", though probably still not ideal, > but is definitely better. This whole discussion is about different shades of OCD. One party wants to clean up as much as possible, another says don't touch my things. I don't think there is an objective "right" way to do things, only something we're able to agree on in the end. I don't really use this feature much myself: if you're able to come to an agreement with Philip (who took the initiative on adding that command), I'll be happy. >>> 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. > > It indeed indirectly services just that one project: but it's also just > another object. Eglot has lots of objects, variables etc., that > "service the project" and project.el fortunately isn't crazy to to touch > them. The buffer in question is an implementation detail of jsonrpc.el. > It's not a buffer of interest in any way for the user or project.el's > manipulations. And it's only a buffer because buffer's are Emacs' > common way of communicating with external entities, and jsonrpc.el uses > that technique. But it could use some other way, say another > process-filter or function calls into C code of a dynamic library. > There would also be objects that indirectly "service" the project, but > not buffers. Most object types are garbage-collected when no live reference to them remains. That's not the case for buffers. Is the buffer in question killed when the user calls 'M-x eglot-shutdown'? If so, consider that, after the user calls project-kill-buffers, there won't be any buffers remaining that belong to that project, that the user would be able to call 'M-x eglot-shutdown' from. >>> 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. > > I M-x cd in *scratch* all the time. It's a global scratch pad, > now accessible via scratch-buffer everywhere. And I don't have any projects that "~" belongs to. >>> * 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. > > You should think your solution through before comparing with the ones > provided so far, which have been tested. Where in the source code would > you even set kill-buffer-query-functions? Eglot code in jsonrpc.el?? Same place you changed the major mode in the last patch: jsonrpc.el. If jsonrpc.el doesn't want its buffers to be killed, it could set that up as described above, through kill-buffer-query-functions. > Not to mention duplicating the eglot-autoshutdown check in unrelated > places is pretty ugly. > >>> 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. > > In the original conversation: > > https://github.com/joaotavora/eglot/discussions/822#discussioncomment-2053395 It's a reasonable approach too. Just not the one we took here. It would make sense to try to make it work first. And if we're comparing different commands similar to this one, how does `projectile-kill-buffers' behave?