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: Mon, 31 Oct 2022 20:58:57 +0000 Message-ID: <87edunvhf2.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> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13404"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 58839@debbugs.gnu.org, manuel.uberti@inventati.org, philipk@posteo.net To: Dmitry Gutov 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 21:58:23 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 1opbrS-0003HK-QJ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Oct 2022 21:58:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opbr9-0000rm-KE; Mon, 31 Oct 2022 16:58: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 1opbr8-0000jL-6l for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 16:58: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 1opbr7-0000PG-W3 for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 16:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1opbr7-000243-PG for bug-gnu-emacs@gnu.org; Mon, 31 Oct 2022 16:58: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: Mon, 31 Oct 2022 20:58: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.16672498777925 (code B ref 58839); Mon, 31 Oct 2022 20:58:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 20:57:57 +0000 Original-Received: from localhost ([127.0.0.1]:42039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opbr3-00023l-0V for submit@debbugs.gnu.org; Mon, 31 Oct 2022 16:57:57 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:45634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opbr0-00023X-QH for 58839@debbugs.gnu.org; Mon, 31 Oct 2022 16:57:55 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id y16so17635657wrt.12 for <58839@debbugs.gnu.org>; Mon, 31 Oct 2022 13:57:54 -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=lsn3XQe7Ji5EgsyBMz3YSrRqnULH2tUMqWo2j9RseZE=; b=g12U5DJh2JEbSwR3kZ5cv81YV5lFwM//1OX7oz1BnWfKqCoAtLg77OZTVQqRxNwBSU mt4jQZCJbjPMUMwXewPitd+R6n6vYyVL2ql0yYeq0LajUrPMQeiD7cmyuoK1oSFW5WZ0 kAL9FYhE+xzOFBfn9HZS2BSUh0iotp2u3MdJdpAKfaJX/840u9WFBn3H5g7XYGiZnOTS rVqKKbxIY0JBcFmlKlDdlCBKKCGUEG+bca6SaqwG8rsCqhcZInB+18b7hkOutWmO61h7 HLrwO8JB+5QOYz9lOvXarJfY6OoCMbu6hlVnX0hsnr+jwhJBiZBVcW8LoZfe+XDod8e2 fE4A== 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=lsn3XQe7Ji5EgsyBMz3YSrRqnULH2tUMqWo2j9RseZE=; b=FxSJF9hU3u7CR8Uwar5xzlIbL6doVwDWZnXgitrCCr0PztUVssF9CHK9HXKmIf5clg /P8+i9AkOGIvl115FJ/HjstJGgKxcGonGP9xPb9wsWmaQXMD7m5434RIMG/ex1bYA21j l+RMDNJXImPOA/GNRYEbN2lP+FZAMMV6kU/OPmIGxxwVug69KuFRkcwsYqijG9GCXG// pAFF7VVpCNTKNAtKXa89FdhRWjeaIVaxCC+BWgW1bwfTjgiQ4dGMn+vC4095mHH/5bUc fuYLmVOV1ikpvxTjeOLU2hKBk4hqRHTXSNG0JY8/5mFWgGksMHPRGo+ItRewWXUuvmPD /99w== X-Gm-Message-State: ACrzQf2n5Za8sKAyX+2FF2Rw1lccstvT+Pc9pvAgFMJY8U9yCHzyWcXt 8aOVAbUoq03waP66RSlAbyA= X-Google-Smtp-Source: AMsMyM6rYjIniTz20tqNcgcPRZ5G6txt3YpLAOrQw1OfglCh6aWJbxJ3rA4+/3RPwmbl3ZK6fYporw== X-Received: by 2002:a5d:494f:0:b0:236:a691:676c with SMTP id r15-20020a5d494f000000b00236a691676cmr9624087wrs.51.1667249868669; Mon, 31 Oct 2022 13:57:48 -0700 (PDT) Original-Received: from krug ([87.196.74.163]) by smtp.gmail.com with ESMTPSA id k18-20020adfe3d2000000b00236705daefesm8005441wrm.39.2022.10.31.13.57.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Oct 2022 13:57:48 -0700 (PDT) In-Reply-To: <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> (Dmitry Gutov's message of "Mon, 31 Oct 2022 19:24:02 +0200") 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:246723 Archived-At: 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. 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. >> 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. 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. 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? >> 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. >> 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. > 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?