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: Tue, 1 Nov 2022 00:51:53 +0200 Message-ID: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@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> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@yandex.ru> <87v8o3wgq1.fsf@gmail.com> <87ilk2x1si.fsf@gmail.com> <871qqq7l9p.fsf@posteo.net> <87eduqwekz.fsf@gmail.com> <87wn8invbx.fsf@posteo.net> <877d0iw8iq.fsf@gmail.com> <837d0hhlke.fsf@gnu.org> <46ff0065-5645-ef1e-2621-242fb6a73f98@yandex.ru> <87v8o0uxn5.fsf@gmail.com> <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> <87edunvhf2.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="19803"; 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: philipk@posteo.net, Eli Zaretskii , manuel.uberti@inventati.org, 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+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 31 23:53:18 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 1opdef-0004wp-Ow for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Oct 2022 23:53:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opdeS-0006KU-J4; Mon, 31 Oct 2022 18:53:04 -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 1opdeQ-0006KM-Bf for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 18:53: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 1opdeQ-0002i8-1x for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 18:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1opdeP-00050f-TM for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 18:53: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: Mon, 31 Oct 2022 22:53: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.166725672519191 (code B ref 58839); Mon, 31 Oct 2022 22:53:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:52:05 +0000 Original-Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opddU-0004zS-BT for submit@debbugs.gnu.org; Mon, 31 Oct 2022 18:52:04 -0400 Original-Received: from mail-wm1-f50.google.com ([209.85.128.50]:44957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opddS-0004yx-6q for 58839@debbugs.gnu.org; Mon, 31 Oct 2022 18:52:02 -0400 Original-Received: by mail-wm1-f50.google.com with SMTP id bg9-20020a05600c3c8900b003bf249616b0so8939470wmb.3 for <58839@debbugs.gnu.org>; Mon, 31 Oct 2022 15:52:02 -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=+45H8LbZ0x7DUGVyAk4acA3gSCW5RKrP6pZg7ztxMSs=; b=kvavcqMDTHjq7Mj/8IgdxPuokayyIz2vdMMtr+g1NncTi0MSl42VXw6npf3s/ACVHv giSp+kem0qx4LifH13QIShajWu3rflD/WsPgAN8e8/s99CwzKvi1hhLuVN6Bc2lgSoYh 7q6RrawvtfSRZL8T43JeBMWkU616S5ZQ9+fdKTpry6ACPOhj2nYeMTY2lD9MxG52Afi3 fnonWMABfJ63DWkmGAyij/g5fOcURmcc8jotuGH24Ett2ydIJ7hRMZlVuVT8esiQaOad lq7fOwrstR6wFVrwHew3eObHtljWj4/q/QHBSVrZrUzDmZyamQNX/8UXw5WwoPQE6shv H5FA== 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=+45H8LbZ0x7DUGVyAk4acA3gSCW5RKrP6pZg7ztxMSs=; b=MBceVCnAlCs7IaUnZiUKGfFLGluou45hdI5cs/iJYtm9nxG5dGE1LLwU1FvnBlOfXb D0TIedypBRQjSSpsQeGUkJyRKcO9lt6mGzc0UwMpnsF0mCaMkahkrX5pClPuJCukGAfF MEzxHO2YCyqUurNl5DJvAcUw8KzDKRB7IrlsUXNZEAlQr/qvSJWxGwKkqx8AEO4ivAAI XivwbRW7rj3dewWPtOZTuHD+IMwoPaszynF5/k+iEswwWH5RyLS5nXigBPKGEmqn32R5 wzM9vDBk5V3+43M9L/I5LNrHNhdK0vtF8peDnZ8be2tA3YESk13bzzY7LMr1UEVe4Grg vC4w== X-Gm-Message-State: ACrzQf24+f++0BlvZEFLKGh8vqyDUtXRbONtwrI6kcNTMV10BvYV3p5+ ckhOBavct9bHiNE4TRIkYOs= X-Google-Smtp-Source: AMsMyM57hpk9nIlTB7L3luEJaoTHhpq+Lx1sDf8mRoQcBCCOSQ3A9NAcSXAPW7tUegBQnUoZ4KL//A== X-Received: by 2002:a05:600c:21a:b0:3cf:6e78:8e89 with SMTP id 26-20020a05600c021a00b003cf6e788e89mr6055012wmi.46.1667256716454; Mon, 31 Oct 2022 15:51:56 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bx10-20020a5d5b0a000000b0022e47b57735sm8431352wrb.97.2022.10.31.15.51.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 15:51:56 -0700 (PDT) Content-Language: en-US In-Reply-To: <87edunvhf2.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+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246729 Archived-At: On 31.10.2022 22:58, João Távora wrote: > Dmitry Gutov writes: > >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index ac278edd40..1e7573c740 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -1223,7 +1223,9 @@ project-display-buffer-other-frame >> (defcustom project-kill-buffer-conditions >> '(buffer-file-name ; All file-visiting buffers are included. >> ;; Most of the temp buffers in the background: >> - (major-mode . fundamental-mode) >> + (and >> + (major-mode . fundamental-mode) >> + (not "\\` ")) >> ;; non-text buffer such as xref, occur, vc, log, ... >> (and (derived-mode . special-mode) >> (not (major-mode . help-mode))) > > Thanks. If that works, go ahead and push it. I suggest you try it first. Last time I launched Eglot was around several months ago. > This should work around this specific bug and then we can open another > one to follow up on all the disaster that has unfolded since. Disaster, really? >>> In the little time I've used this feature since the start of this >>> discussion I have discovered it backfires no small number of occasions: >>> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,... Heck >>> even *ibuffer* itself is targeted by this. >> Of course it is targeted: we want ibuffer buffers to be killed just as >> well when killing a project. And sly-scratch, and etc. > > No, we don't want. *sly-scratch* is a global scratchpad for the Common > Lisp connection that can "service" many Common Lisp projects, to use > your own terminology. Okay, you're probably right about at least some of those. > Do you know what M-x ibuffer does? It's a manager for all the buffers in > all the projects in Emacs. In the earmuffed *ibuffer*, it gives you an > overview of all visited buffers, sorted and organized by various > criteria. Again, *ibuffer* can't possibly be taken to "service a > project". Destroying this buffer's state because the user decided to > kill a project is simply wrong. It's very plain to see that. I must have been thinking about project-* or projectile-* counterparts. Like projectile-ibuffer or the homemade version for project.el made by a user in a bug report nearby. > And *Shell Command Output* where it is impossible to know in advance if > the contents refer to a specific project or not. It depends on what the > user typed after M-|! > > And the Gnus buffers? And the CIDER report? Do you know whether CIDER will be satisfied by the same patch I sent previously? >>> you're making a gun that only backfires 5% of the time. >> Yours is the first instance so far. > > We seem to use different algebraic systems. This is literally the first bug report on the subject. >>> The mini-languages invented in project-kill-buffers-conditions and >>> project-ignore-buffer-conditions are abominations. >> This is the point where I'd normally blacklist you again. > > I had no idea who authored those variables. If you are among the > authors, I'm very sorry, I was referring merely to code. I said before > I'm quite happy with project.el, but this (small) part of it is very > badly done. I'm not the only author. Regardless, it's not a good language to use no matter who wrote it. What you are doing is pressuring all other participants into your POV by means of an insult. That usually works better if the offending code was written by somebody who already left (the project/the discussion/the company/etc), or is a little younger. >> They are not much better than the "patch" I showed for Eglot, >> correctness-wise. > > Of course they are, they are opt-in. So project.el's C-x p k doesn't > destroy packages' essential buffers just because of some overly greedy > heuristic. Using this idea, we make a conservative heuristic better, on > a case by case basis. > >> And mine would make it safe against any kill-buffer calls, including >> ones issued by the user. > > Should I really to explain again that a hidden buffer is hidden from the > user and thus he can't reasonably M-x kill-buffer on it? They can, though, even if odds are low. It can also happen through some other automation, which Emacs lets the users do freely. I'm fairly sure that the solution I offered would be easy enough implement, to actually protect the vulnerable buffer. I suppose we are not doing that, however.