From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Date: Wed, 02 Nov 2022 08:36:00 +0000 Message-ID: <8735b1bvnz.fsf@posteo.net> References: <87sfj8umwb.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> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@yandex.ru> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@yandex.ru> <87a659u7vo.fsf@gmail.com> 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="13381"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , manuel.uberti@inventati.org, 58839@debbugs.gnu.org, Dmitry Gutov 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 Wed Nov 02 09:37:34 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 1oq9Fd-0003GG-Nt for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 09:37:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oq9FH-0001Zg-SE; Wed, 02 Nov 2022 04:37:11 -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 1oq9F8-0001XH-Pf for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:37:09 -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 1oq9F7-0000kQ-VK for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oq9F7-0002jM-R7 for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 08:37: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.166737817210437 (code B ref 58839); Wed, 02 Nov 2022 08:37:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:36:12 +0000 Original-Received: from localhost ([127.0.0.1]:44891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq9EJ-0002iH-VS for submit@debbugs.gnu.org; Wed, 02 Nov 2022 04:36:12 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:48461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq9EI-0002hy-2z for 58839@debbugs.gnu.org; Wed, 02 Nov 2022 04:36:10 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 46C7D240106 for <58839@debbugs.gnu.org>; Wed, 2 Nov 2022 09:36:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667378164; bh=Ot+q00dZUOP5YSKK0ieXy3UMuqGDwaectKAK4GN256Y=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=QhjJ49KF4B7aZ2Q4RttqOhq/uXIAuSFsJ/KeZa2iIz89pGP28FssxUd1jXkw3gSpG QcU9JANkuEyWERNCb88eL00scyRaLta838KuPQlgYRZH3Fq0Bd3OG3GRhLVNxXCRey sJtWUL9dnSsT3LliWzOeowwFJ1psVkqX+AAU26N+4uwBR+k8dwXZp9Vgf97vFopwfW XUdNnG5fs03rYzqlgnOkY1sgYp7XZJQ5D70gXD7O3Dz6RAwJap5ZMXi/0U0n2kebOb 6keGvzRfj/4FInfHZUZsKHKebz+bCcTd3QWA/FZdvbLHGmvDw8bWmAmxUw3OiUOcXa aY6qsuqcl9c2g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2Kwc6RpXz6tn3; Wed, 2 Nov 2022 09:36:00 +0100 (CET) In-Reply-To: <87a659u7vo.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 07:34:51 +0000") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB 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:246850 Archived-At: In general I'd like to remind everyone of the GNU Kind Communication Guidelines, because the tone of the discussion in this issue report has been unpleasant for a few days now. Jo=C3=A3o T=C3=A1vora writes: > Dmitry Gutov writes: > >>> I've explained to Philip objective reasons why I think evaluated >>> mini-languages are almost always inferior to a decent Lisp such as Elis= p. >>> You could perfectly reasonably deprecate these two variables. >> Not where this discussion is going, is it? > > Not sure. This started has a report of hidden buffer being incorrectly > killed by project.el.=20=20 The issue that was reported was that Eglot/jsonrpc raised an error that broke `project-kill-buffer'. This could have also all been solved by wrapping a `with-demoted-errors' around `kill-buffer'. > After much insistence, you've agreed to plug the > hole in that library. During tests I also discovered that project.el is > killing other buffers nonsensically, like Gnus buffers, *ibuffer*, and > many other global. It was actually easier to find false-positives of > your heuristic than true ones. Again, after some insistence, you seem > to have come around that these things represent bugs. > > Three people here have suggested an opt-in approach for the true > positives. Now your strategy seems to be "OK: let all these false > positives remain nonsensically associated with a project in > project-buffers but let's have global databases of exceptions for > specific operations, using a (largely redundant) mini-language for > buffer-matching". For the record, I am still not convinced 100% either way. Whether or not whitelisting or blacklisting is the better approach will concretely depend the list of misjudgments that the current condition makes. > If that doesn't sound like a bad idea in the face of much better other > ideas, I don't know what else to tell you. > >>> > 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. >>> You sketched an untested code-less idea and I explained how flawed >>> it was. >> >> Back atcha. Modulo "code-less". > > Not only did I provide code, I also verified that it works. Anyone can > see my messages to verify that. > > Jo=C3=A3o