Received: (at 58839) by debbugs.gnu.org; 4 Nov 2022 11:21:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 04 07:21:31 2022 Received: from localhost ([127.0.0.1]:51919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oqulP-00077z-5I for submit <at> debbugs.gnu.org; Fri, 04 Nov 2022 07:21:31 -0400 Received: from mail-ej1-f51.google.com ([209.85.218.51]:36822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <contovob@HIDDEN>) id 1oqulK-00077i-CS for 58839 <at> debbugs.gnu.org; Fri, 04 Nov 2022 07:21:28 -0400 Received: by mail-ej1-f51.google.com with SMTP id 13so12477510ejn.3 for <58839 <at> debbugs.gnu.org>; Fri, 04 Nov 2022 04:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; 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=1A57DIGaEHch7sEXUCPK+/5QZEfW9G1KZIMGQfHo36o=; b=PCG8wNE2h8Z2CFXrXFsYs1QS8Of1Cl3RAXNYv1UQp23l0yIGm3AED5j1Ixc5HTAhEr ji0rKJiSgb6XW2VfOgTquY70XlxlOpmOQvldO90j8meRbKwY7t06oP0JykJ6eTf1RhVX kl0r18gCb9Yc+LZAZW1xOFf77hl7wJh/c4g00MZmE2HFjhax/Jnhdz7N/EuOTKYa4+2Q VXRAi+5kP3VMplQdieplvmY+dOgpZ2LpWGevF3ECpQKdCz8pthNCnaOLVOb++22afrd7 WW5sdEX+YfLg/K5LLFzhsJeKt2qlfJmX8GLVu2CY91JQW7d9796fpThyIvN+luJCCdI3 ra2Q== 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=1A57DIGaEHch7sEXUCPK+/5QZEfW9G1KZIMGQfHo36o=; b=tileF0Qm+ef884objC5ydvYpSuCp2Ytu5HG4hYoN4af4H0DjWtOvvBHk1GhQ3TzAB9 C4KpFM0wZSDrYktMrKyRyGs3lQ5Xx0qCG50a2+oX1wt+iCKnMrbtM5Ex50GgGwPaiHga C+Pip3lBCZWqMl7pCrnltufx0mPmchj1a8CSmGUaKrj4orR5vzU0gu0iF7csJTBRVFNv dh5JZxCVF4cjFogeoyAb+AbPMyLt6eVDHt+TIYX/WjVwi8k4vy8S7zyjmmj6cePr+6CB ozlDNEIdoVNHNxSWpTv3zEZPKjRqH9PPfbIm5ENIrH0Qk2t0qDGLb8KifLzfjvUNcSMS SGbw== X-Gm-Message-State: ACrzQf1bM/imOLBqgkzzkSF70aQDiXcKgf2KFjJTm2QnHouV5hmaHXeB K+fL89zLvxJvzz2hGyIKr8Q5aQ== X-Google-Smtp-Source: AMsMyM7r8GbZT61l+vs8PX6BpNhCb6CjsbfanstbiNMn4/XuSFMp64GlwvOe7qIBzMCtW9eX71NlLw== X-Received: by 2002:a17:907:7e81:b0:7ad:e144:19e5 with SMTP id qb1-20020a1709077e8100b007ade14419e5mr22954411ejc.51.1667560880102; Fri, 04 Nov 2022 04:21:20 -0700 (PDT) Received: from localhost ([2a02:587:320c:8829:23:8156:16ed:40c2]) by smtp.gmail.com with ESMTPSA id q21-20020a17090676d500b0073de0506745sm1650543ejn.197.2022.11.04.04.21.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 04:21:19 -0700 (PDT) From: "Basil L. Contovounesios" <contovob@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> (Dmitry Gutov's message of "Mon, 31 Oct 2022 19:24:02 +0200") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> Date: Fri, 04 Nov 2022 13:21:17 +0200 Message-ID: <871qqj55jm.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov [2022-10-31 19:24 +0200] wrote: > 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 "\\` ")) AKA "\\`[^ ]" here and elsewhere, FWIW. Thanks, -- Basil
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 4 Nov 2022 01:13:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 03 21:13:18 2022 Received: from localhost ([127.0.0.1]:51055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oqlGo-0005Qy-2n for submit <at> debbugs.gnu.org; Thu, 03 Nov 2022 21:13:18 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:34609) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1oqlGl-0005Qh-UB for 58839 <at> debbugs.gnu.org; Thu, 03 Nov 2022 21:13:17 -0400 Received: by mail-wr1-f42.google.com with SMTP id k8so5130198wrh.1 for <58839 <at> debbugs.gnu.org>; Thu, 03 Nov 2022 18:13:15 -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=ZEppwYF455OSCQA5rYM0nS02Nn+JiRs1M5r0mRuBOvo=; b=RTuIxQIaTDENLz6dLbXBt+3AGOusKrkkHNmtDNEJg//xcSbVnO8PsU/MxyvHnujI4D 9DuMW/tFLHRd7WW5gm8AB3G5G67QdBTULwbw/3XaYCE3wT1HYEDzm3fjZfejpjThAxrP GNZlqwpHr7CfKIZ2GII8Jv5HwWCx4DiomJ/eFHjF2CYBt1o29DJHVXRmwNumAcMtRR2r 55o7U83o7oJVjLMLn+hEdIQi5E5a2rvD8YM0l+glf6dD32oBR06GIwoTKeolE3hdy+Sh 7HJJpab/muaGy52JPiqQrrB9tpVviH70Idt5B+v7GFPhXlgd1LstHfg/krIlKnrvy4Nn hMbQ== 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=ZEppwYF455OSCQA5rYM0nS02Nn+JiRs1M5r0mRuBOvo=; b=Sk+4kjY4ZiSov6Cz0X0PHdYDbe4VypgmStJaEqZ0zU2R18OZXP4Wknm7NCRDCd00KM GJ2xZZHTsw6GdGGjYJS/qwZLzmStMYVqLi5vnuIgx9myZrnekdxToi0mOhqcFQjcIi43 i28hxaVPrR0bulScFcb3ro9uUWFrOngL4M9cBGBjcQ+nAUHEJ+kKcekf8Nk8/+npDic4 7IajxCh+UFAst+kr81cVHqOaukzr4JmoqB45jIEiWshZWgt5OE7b33ZKmn/IC3TJtecK 9ILU/QcXzMmdGLcqC/2wefeQw+jfwFH6gOy1lZ2T8goqF0qpGgZe35gdjxahMfZjVHFz iOpg== X-Gm-Message-State: ACrzQf1qmo50Fy0n+39vxfBAgbm25cn4SIFnx0/azkFRP6MSUPKhUrdD rVdJqTIBGhKVJV8Eh9wtmog= X-Google-Smtp-Source: AMsMyM59xIWy7PCi7tm+hUkrQEoy0fFdz4vxC4gdJu6NTswGqHnf5Nl09oFGiO6H9gwVHQcG3hABOA== X-Received: by 2002:a5d:554e:0:b0:236:ccf1:f958 with SMTP id g14-20020a5d554e000000b00236ccf1f958mr16374894wrw.378.1667524389794; Thu, 03 Nov 2022 18:13:09 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bu14-20020a056000078e00b0022cdb687bf9sm2967834wrb.0.2022.11.03.18.13.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 18:13:09 -0700 (PDT) Message-ID: <3922d5b4-4afb-e8b9-7b31-11a818c0b751@HIDDEN> Date: Fri, 4 Nov 2022 03:13:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 13:36, João Távora wrote: > On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <dgutov@HIDDEN > <mailto:dgutov@HIDDEN>> wrote: > > > I suggest you try it first. > > It works in my test > > > Disaster, really? > > The reason I came about the Gnus problem was when using it > to reply to some emails here and trying out the C-x p k and finding out > all my Gnus buffers were gone. I have now pushed the proposed fix, as well as an additional change to except Gnus modes (not sure it will be enough -- there might be background buffers using some modes that don't derive -- but it seems to help in my brief testing). That's not to mark a final decision, but to fix the immediate issues, and to remember them in the code. The question now is how to better handle packages and features that are similar to Gnus in that regard. One alternative option would be to add a var through which such modes could opt-out (rather than opt-in). It seems more likely that we won't have to update project-kill-buffer-conditions often then. A whitelisting approach seems cleaner/safer, though.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 3 Nov 2022 18:19:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 03 14:19:42 2022
Received: from localhost ([127.0.0.1]:50604 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oqeoY-0000qm-4M
for submit <at> debbugs.gnu.org; Thu, 03 Nov 2022 14:19:42 -0400
Received: from mail-oi1-f174.google.com ([209.85.167.174]:40499)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1oqeoW-0000qY-J1
for 58839 <at> debbugs.gnu.org; Thu, 03 Nov 2022 14:19:41 -0400
Received: by mail-oi1-f174.google.com with SMTP id n186so2850244oih.7
for <58839 <at> debbugs.gnu.org>; Thu, 03 Nov 2022 11:19:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=BeArjrfNkZ4KeKSKpmyOSlIkMTPAGlJ/i67Abk1sjxo=;
b=fqHyvmAJdUvbI4PTK8oNqLySC6ltK4gkA7T+Z2Xi1PmJd1PU9feP6FF0pdQ9F76S9c
5vBkKb0+pBGN69nwk+RPUSi3AkMaQ6p/mCxOJ3XNOJ5hpFVSNHfPLBv4GoXzK4F6zH9O
oTUsbVRICMoPfinx0lDnBFb0aEqI4A5/sJgN5A3lXX0q+0+IvBCcBCihIw2KoVvn7C7M
UU38AK7cejvYr/KbQkoHJCMLk6uvFdVRaNy/9UmuEDJj/5elGv8gPUEJ6gxbgITVPK0D
LS1pSayPkx24xENIZh60/O6lovho4HD1MxaOkThifHET+G5P7LKxHV9v5pRSOKaQmh0P
LtJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=BeArjrfNkZ4KeKSKpmyOSlIkMTPAGlJ/i67Abk1sjxo=;
b=DcHfUYverjSDr8sN0pZRWj+TrTs3ESlkWOQpQuVtBpXhCxVIc9SI3iX3QV69tlS+B6
GS/PsbW1h4T9wsZPwaO3jfdpl2C+QboAvoOPVeGgr9s0ZafnR/MCMffHbWiz0yw9hxIq
eTe+WUeq/oIi2ze9fppT+SLXcDW3H7BLz1tVBzG+njJjQH73svqO0+E9O/44wIijHzbv
SVWOAjRG1x2oBTY6U+6heZlBqNDVA83r/a/aggkQRJeRHbUADwMfsJrDfZtDnvfCvHlD
KZ3VIxUNgZZlKp38nhnfiEKH4bY62Y9BjeRIhtX5DrSOH9Uh2MvwO17eRs3+EOGuA9NI
dXHA==
X-Gm-Message-State: ACrzQf0hU8J44OeAlFxHDcecsOgjKIMtdT0eT3bZAz6USgXXJewMe3ri
EZezjX/15APWSEWzZrmkVB/yX5/SOInBTCGrzDE=
X-Google-Smtp-Source: AMsMyM6Xp1I6f/kK7AXaixelsiXpFK183sib/waUIHgyILLSqcfnyJn/gJUG+J9MCg/Qbqs4zB+OktK8s0XROqO3aS8=
X-Received: by 2002:a05:6808:a05:b0:35a:2a65:eb01 with SMTP id
n5-20020a0568080a0500b0035a2a65eb01mr8552965oij.215.1667499573698; Thu, 03
Nov 2022 11:19:33 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
<871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
<87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
<6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN>
<8735b1bvnz.fsf@HIDDEN> <87mt99spsk.fsf@HIDDEN>
<87r0ylafdl.fsf@HIDDEN>
<87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
<86mt991dst.fsf@HIDDEN> <86o7tojda2.fsf@HIDDEN>
In-Reply-To: <86o7tojda2.fsf@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Thu, 3 Nov 2022 18:19:20 +0000
Message-ID: <CALDnm51U-aswy6TRfx4hG39tXe9gMiV_Z-WVr9C+abQrktSsdw@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
To: Juri Linkov <juri@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c0e51605ec94ffb8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--000000000000c0e51605ec94ffb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Juri, this doesn't seem right. Eglot shouldn't be turning itself on in
hidden buffers to start with: It's totally useless there.
So you have to explain an Emacs -Q recipe that demonstrates how Eglot
reached this nonsensical state. You haven't done that (or have you and i
have missed it?).
I tried project-find-regexp with Eglot-managed files with no problems, but
I have no idea what you're doing.
Also, this problem is totally off-topic here: this is about
project-kill-buffers. Please start as new issue of you haven't already.
Jo=C3=A3o
On Thu, Nov 3, 2022, 17:39 Juri Linkov <juri@HIDDEN> wrote:
> > OTOH I completely support the request to make Eglot more resilient
> > to unforeseeable situations. Currently it's so brittle, so I get a lot
> > of such errors all the time:
> >
> > Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
> > file-truename(nil)
> > eglot--path-to-uri(nil)
> > eglot--TextDocumentIdentifier()
> > eglot--signal-textDocument/didClose()
> > kill-buffer(#<buffer *xref-temp*>)
> > xref--convert-hits(...)
> > xref-matches-in-files("word" ...)
> > project--find-regexp-in-files("word" ...)
> > apply(project--find-regexp-in-files ("word" ...))
> > xref--show-xref-buffer(...)
> > xref--show-xrefs(...)
> > xref-show-xrefs(...)
> > project-find-regexp("word")
> > funcall-interactively(project-find-regexp "word")
> > command-execute(project-find-regexp)
>
> Here's a patch that fixes this:
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index c5870618372..5b05f84c63c 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode
> (unless eglot--managed-mode
> ;; Called when `revert-buffer-in-progress-p' is t but
> ;; `revert-buffer-preserve-modes' is nil.
> - (when (and buffer-file-name (eglot-current-server))
> + (when (and buffer-file-name
> + (not (string-match-p "\\` " (buffer-name)))
> + (eglot-current-server))
> (setq eglot--diagnostics nil)
> (eglot--managed-mode)
> (eglot--signal-textDocument/didOpen))))
>
--000000000000c0e51605ec94ffb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Juri, this doesn't seem right. Eglot shouldn't be=
turning itself on in hidden buffers to start with: It's totally useles=
s there.<div dir=3D"auto"><br></div><div dir=3D"auto">So you have to explai=
n an Emacs -Q recipe that demonstrates how Eglot reached this nonsensical s=
tate. You haven't done that (or have you and i have missed it?).</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I tried project-find-regexp wi=
th Eglot-managed files with no problems, but I have no idea what you're=
doing.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, this probl=
em is totally off-topic here: this is about project-kill-buffers. Please st=
art as new issue of you haven't already.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Jo=C3=A3o</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 3, 2022, 17:39 Juri Linkov =
<<a href=3D"mailto:juri@HIDDEN">juri@HIDDEN</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">> OTOH I completely support the reque=
st to make Eglot more resilient<br>
> to unforeseeable situations.=C2=A0 Currently it's so brittle, so I=
get a lot<br>
> of such errors all the time:<br>
><br>
> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)<br>
>=C2=A0 =C2=A0file-truename(nil)<br>
>=C2=A0 =C2=A0eglot--path-to-uri(nil)<br>
>=C2=A0 =C2=A0eglot--TextDocumentIdentifier()<br>
>=C2=A0 =C2=A0eglot--signal-textDocument/didClose()<br>
>=C2=A0 =C2=A0kill-buffer(#<buffer=C2=A0 *xref-temp*>)<br>
>=C2=A0 =C2=A0xref--convert-hits(...)<br>
>=C2=A0 =C2=A0xref-matches-in-files("word" ...)<br>
>=C2=A0 =C2=A0project--find-regexp-in-files("word" ...)<br>
>=C2=A0 =C2=A0apply(project--find-regexp-in-files ("word" ...)=
)<br>
>=C2=A0 =C2=A0xref--show-xref-buffer(...)<br>
>=C2=A0 =C2=A0xref--show-xrefs(...)<br>
>=C2=A0 =C2=A0xref-show-xrefs(...)<br>
>=C2=A0 =C2=A0project-find-regexp("word")<br>
>=C2=A0 =C2=A0funcall-interactively(project-find-regexp "word"=
)<br>
>=C2=A0 =C2=A0command-execute(project-find-regexp)<br>
<br>
Here's a patch that fixes this:<br>
<br>
diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el<br>
index c5870618372..5b05f84c63c 100644<br>
--- a/lisp/progmodes/eglot.el<br>
+++ b/lisp/progmodes/eglot.el<br>
@@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode<br>
=C2=A0 =C2=A0(unless eglot--managed-mode<br>
=C2=A0 =C2=A0 =C2=A0;; Called when `revert-buffer-in-progress-p' is t b=
ut<br>
=C2=A0 =C2=A0 =C2=A0;; `revert-buffer-preserve-modes' is nil.<br>
-=C2=A0 =C2=A0 (when (and buffer-file-name (eglot-current-server))<br>
+=C2=A0 =C2=A0 (when (and buffer-file-name<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not (string-match-=
p "\\` " (buffer-name)))<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(eglot-current-serv=
er))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(setq eglot--diagnostics nil)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(eglot--managed-mode)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(eglot--signal-textDocument/didOpen))))<br>
</blockquote></div>
--000000000000c0e51605ec94ffb8--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 3 Nov 2022 17:39:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 03 13:39:46 2022
Received: from localhost ([127.0.0.1]:50402 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oqeBu-0003eP-5J
for submit <at> debbugs.gnu.org; Thu, 03 Nov 2022 13:39:46 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:39305)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1oqeBq-0003e8-L7
for 58839 <at> debbugs.gnu.org; Thu, 03 Nov 2022 13:39:44 -0400
Received: (Authenticated sender: juri@HIDDEN)
by mail.gandi.net (Postfix) with ESMTPSA id 6FCBE60006;
Thu, 3 Nov 2022 17:39:33 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: 58839 <at> debbugs.gnu.org
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <86mt991dst.fsf@HIDDEN> (Juri Linkov's message of "Wed,
02 Nov 2022 19:32:02 +0200")
Organization: LINKOV.NET
References: <87sfj8umwb.fsf@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
<871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
<87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
<837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
<6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
<87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
<87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
<87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
<86mt991dst.fsf@HIDDEN>
Date: Thu, 03 Nov 2022 19:30:13 +0200
Message-ID: <86o7tojda2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 58839
Cc: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
> OTOH I completely support the request to make Eglot more resilient
> to unforeseeable situations. Currently it's so brittle, so I get a lot
> of such errors all the time:
>
> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
> file-truename(nil)
> eglot--path-to-uri(nil)
> eglot--TextDocumentIdentifier()
> eglot--signal-textDocument/didClose()
> kill-buffer(#<buffer *xref-temp*>)
> xref--convert-hits(...)
> xref-matches-in-files("word" ...)
> project--find-regexp-in-files("word" ...)
> apply(project--find-regexp-in-files ("word" ...))
> xref--show-xref-buffer(...)
> xref--show-xrefs(...)
> xref-show-xrefs(...)
> project-find-regexp("word")
> funcall-interactively(project-find-regexp "word")
> command-execute(project-find-regexp)
Here's a patch that fixes this:
diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index c5870618372..5b05f84c63c 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode
(unless eglot--managed-mode
;; Called when `revert-buffer-in-progress-p' is t but
;; `revert-buffer-preserve-modes' is nil.
- (when (and buffer-file-name (eglot-current-server))
+ (when (and buffer-file-name
+ (not (string-match-p "\\` " (buffer-name)))
+ (eglot-current-server))
(setq eglot--diagnostics nil)
(eglot--managed-mode)
(eglot--signal-textDocument/didOpen))))
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 18:15:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 14:15:25 2022 Received: from localhost ([127.0.0.1]:47146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oqIGq-0005qO-T7 for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 14:15:25 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:44029) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oqIGp-0005qA-41 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 14:15:23 -0400 Received: by mail-wr1-f41.google.com with SMTP id g12so25719175wrs.10 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 11:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=ZjydSnWPQwAnNtmqHXHYKoSgigP9wifb8CEJ8zJJpg8=; b=GzenMkO90w0AJz6HiLliHKu+puHMqFUNyOoHL8szLc9q4Xs372I9AAKrBPSj5xKUW8 SZedyd2PA9rBIWsIPKEpm22nnluPCizf1SHrgotel0Lz+ERgZNuJcmdmoqlu0Ndz7K94 B+bCxpv+TMdsxXRGTlvB2qVBLLqzPUowIhDZZrfpeqnyH1UhG4mCtWXBOjFiJJcc556G MVFV03aCfOGla9xZFSlgsHp8JYVaLshLYD7hr35kT087iJ7sA5zY+sJVlL7TTT8RtwJb ohC41kTQF5ZGCe3C5xXjGm449hGk02pZt1Xj0OUb9zh2QnTC51ewrvSr19M5qvnJOG8u D+Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=ZjydSnWPQwAnNtmqHXHYKoSgigP9wifb8CEJ8zJJpg8=; b=dG0mNKc9hGQXMLk0xQ+2Jt3W0TEjmILkBDYz8ttPpbAHfIYHV/5emE45bmTMysV1rm +8gZCpXxGzDbAtPd9+qHQC7JWyJXlX221Y/qb3y+KC6SK5MVURFG8LkTFNfkVgguzFx/ HkJu1xghCi6dARZSDp8rRPpu4GNqF6UZJjPI6kCavSzbUHaqsQuFqecbZzc0qEG1Xyvk U5SClW4ohht6VoBwWyFKu4sO3oO1lVwr/Gjhnbk51rLReptJ6d8vEMHCcct01qW5kKQ2 J1j7F+93rSxFDRIbc7D0QKpSn12rvO/LkIeCkE4QQvYHIkiTnj0W/b5VwoesRAIjepKX 2iJw== X-Gm-Message-State: ACrzQf11sZ8BN5n9ioM6M3NRInljiz/ga1Gan2HLCeL58gIQJ9azvDq6 uhBZU/6QzvH5Wa/1mqNuUrprvbc4MP0= X-Google-Smtp-Source: AMsMyM5EEEQ4f0ycmIZoIKQDtAiZO7AdQLkeakEl2gOfPEkOd9f5L0Jf6EdcfLwJL9FRBh/0FnJtsg== X-Received: by 2002:adf:b612:0:b0:236:5d1f:143a with SMTP id f18-20020adfb612000000b002365d1f143amr15668495wre.364.1667412916761; Wed, 02 Nov 2022 11:15:16 -0700 (PDT) Received: from krug (87-196-82-28.net.novis.pt. [87.196.82.28]) by smtp.gmail.com with ESMTPSA id o21-20020a05600c4fd500b003c71358a42dsm3366707wmq.18.2022.11.02.11.15.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 11:15:16 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87r0ylh0y4.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 02 Nov 2022 14:42:59 +0000") References: <87sfj8umwb.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN> <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN> <87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN> Date: Wed, 02 Nov 2022 18:16:18 +0000 Message-ID: <877d0dql1p.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Sorry Philip, but this is a very long email rehashing many things I've addressed repeatedly. I don't have anything to add. I hope Dmitry installs the patch to project.el's project-kill-buffer-conditions that he proposed so that this bug can be closed. Or some other patch like the ones I proposed. Thanks for everything, I'm geting off the merry-go-round now. Jo=C3=A3o Philip Kaludercic <philipk@HIDDEN> writes: [...snipped...]
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 17:51:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 13:51:51 2022
Received: from localhost ([127.0.0.1]:47134 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oqHu3-0005GV-DM
for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 13:51:51 -0400
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:50025)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <juri@HIDDEN>) id 1oqHu1-0005G6-D0
for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 13:51:49 -0400
Received: (Authenticated sender: juri@HIDDEN)
by mail.gandi.net (Postfix) with ESMTPSA id A40EE40003;
Wed, 2 Nov 2022 17:51:41 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <87r0ylh0y4.fsf@HIDDEN> (Philip Kaludercic's message of "Wed,
02 Nov 2022 14:42:59 +0000")
Organization: LINKOV.NET
References: <87sfj8umwb.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
<6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
<87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
<87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
<87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 19:32:02 +0200
Message-ID: <86mt991dst.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
=?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN>,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
>> OK, one last time. First, the above principle of encapsulation has
>> nothing to do with LSP or Eglot or Jsonrpc.
>
> Again, it is not given that this applies to buffers. Robust code should
> be able to handle a missing resource or prevent the resource from being
> revoked. This is not possible with buffers, so this is a design fault
> with Eglot or Jsonprc. *
While the default value of project-kill-buffer-conditions really
looks too wide (especially covering fundamental-mode and special-mode),
OTOH I completely support the request to make Eglot more resilient
to unforeseeable situations. Currently it's so brittle, so I get a lot
of such errors all the time:
Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
file-truename(nil)
eglot--path-to-uri(nil)
eglot--TextDocumentIdentifier()
eglot--signal-textDocument/didClose()
kill-buffer(#<buffer *xref-temp*>)
xref--convert-hits(...)
xref-matches-in-files("word" ...)
project--find-regexp-in-files("word" ...)
apply(project--find-regexp-in-files ("word" ...))
xref--show-xref-buffer(...)
xref--show-xrefs(...)
xref-show-xrefs(...)
project-find-regexp("word")
funcall-interactively(project-find-regexp "word")
command-execute(project-find-regexp)
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 14:43:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 10:43:11 2022
Received: from localhost ([127.0.0.1]:46929 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oqExS-0006jU-W9
for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 10:43:11 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39709)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <philipk@HIDDEN>) id 1oqExR-0006jH-3k
for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 10:43:09 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 92669240027
for <58839 <at> debbugs.gnu.org>; Wed, 2 Nov 2022 15:43:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1667400183; bh=3roSJmNTpjwRyTG2KuL5vChIpLyzYe2+QuXqaftY3vU=;
h=From:To:Cc:Subject:Autocrypt:Date:From;
b=p+RwVeJRveO/CbGP2Qb8R5iQa6e6IX+xuSoCE+LY8txr6E7EroF7NaUnGd1JBuK48
B6ecVO5jbSC7yEOZKKD9sqqQlhkaApHrhDYHBCAcgkMbws7S/NfaVego5dAMTb2oMz
KXa4yFyesesZyEODPzScliq2piX2YGYv7eVCcIvD6K2fRQQ+LSt1c53oD2MZB8MD6U
eGpxuFz8QlixdxEV9JHLsfSUz/7i8tWtbFAend3eMiBxTKm2135WrZbz7Cz6usk70W
5AEsyN2c0Gnk6OGG9w+yUy47W6+OAuGUv5ERCm36rso8RDaPnxb7yi3/0XDWhqdXzD
UPlcaVTyb1/7w==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4N2V463CxNz9rxK;
Wed, 2 Nov 2022 15:42:59 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <87cza5sbfx.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 14:00:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
<6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
<87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
<87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
<87cza5sbfx.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 14:42:59 +0000
Message-ID: <87r0ylh0y4.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> Philip Kaludercic <philipk@HIDDEN> writes:
>
>> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>>
>>> Philip Kaludercic <philipk@HIDDEN> writes:
>>>
>>>>> Not sure. This started has a report of hidden buffer being incorrect=
ly
>>>>> 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'.
>>>
>>> No. It couldn't. The error is there to show you among other things
>>> that the LSP connection isn't being shut down correctly, which is not
>>> something to paper over. And even if you did paper over the error, you
>>> would break eglot-autoshutdown. I've explained that at least 3 times
>>> already in the beginning of this discussion.
>>
>> That was not my concern, my concern was that project-kill-buffer
>> broke. I continue to not see a reason why project.el should be
>> considered broken because of this, and not jsonrpc/eglot.
>
> It was always broken since the way it was created. Eglot's precedes it,
> I've also explained this.=20=20
This is not an argument.
> You can't kill a internal hidden buffer just
> because you can see it anymore than you unintern some "--" symbol in
> obarray simply because you can see it and don't like its inelegant name,
> or you think it's taking too much RAM. I can't really explain this any
> other way.
The equivalence is not given, more so because there is no package that
manages symbols the way that project.el manages buffers. If this is
all, your argument, or rather statement, is simply not convincing, no
matter how often it is reiterated. *
>> This is probably best solved by reading code. Can you point me to a few
>> functions/section/etc. that would help me clarify the situation.
>> I haven't made up my mind, I am just trying to understand all
>> perspectives, and get a better overview over the issue.
>
> OK, one last time. First, the above principle of encapsulation has
> nothing to do with LSP or Eglot or Jsonrpc.
Again, it is not given that this applies to buffers. Robust code should
be able to handle a missing resource or prevent the resource from being
revoked. This is not possible with buffers, so this is a design fault
with Eglot or Jsonprc. *
> Specifically in Eglot, as I already explained, eglot.el and jsonrpc.el
> colaborate so that jsonrpc.el holds a network process to communicate
> with the LSP server. It uses a buffer for more convenient and efficient
> parsing of messages. That buffer is out of bounds for Eglot (and anyone
> else).=20=20
Can I `switch-to-buffer' into it, can I `kill-buffer' it? Yes? So it
is not out of bounds, and a mistake was made in the design by assuming
this is the case. *
E.g. why does the buffer have a default directory?
> Eglot doesn't know or care that a buffer is being used, it only
> actuate on the handle using operations of jsonrpc.el's API. According
> to user options, Eglot provides controlled shutdown and reconnection
> using these operations.
OK, these appear as convince options that can be used, but don't prevent
me from killing any buffers. *
> All of this has worked for a long time and predates project.el's buffer
> collection/killing/switching logic.
Again, this is not an argument, just a statement of fact that doesn't
imply anything definitive. From the same statement I can also infer
that jsonrpc/Eglot had an undetected bug that was exposed by project.el.
You are committing an informal logical fallacy by assuming some kind of
temporal order in the attribution of mistakes. *
> If you or some Lisp package finds and destroys the hidden implementation
> detail, all the above is broken. Therefore packages like project.el
> that do it are buggy in that regard.
This is a "If it can be destroyed by the truth, it deserves to be
destroyed"-kind of thing. Double-dash symbols are "private" by
convention, but that might change in the future. Hidden buffers are
just not displayed, as said in the manual (found via the index):
Buffers that are ephemeral and generally uninteresting to the user
have names starting with a space, so that the =E2=80=98list-buffers=E2=
=80=99 and
=E2=80=98buffer-menu=E2=80=99 commands don=E2=80=99t mention them (but =
if such a buffer visits a
file, it *is* mentioned). A name starting with space also initially
disables recording undo information; see *note Undo::.
The keywords being "ephemeral and generally uninteresting", not "private
and off-limits" This is not the same kind of thing like with a symbol
that was generated using `make-symbol', where you are guaranteed nobody
can access it without being passed the symbol directly or via some dirty
hacks. And just so it is clear, using `buffer-list' is not a dirty
hack. *
If you need private buffers, you either need to argue that the
convention be clarified in the reference manual or have these
implemented in such a way (e.g. by passing a flag to
`get-buffer-create') nobody can access a private buffer without being
passed the buffer object or via some dirty hacks. And just so it is
clear, using `buffer-list' is not a dirty hack.
* These are all "Strong Opinions, Weakly Held", I really don't care
about it too much. What I don't like about this discussion is the
tone you take in postulating the mistake was made somewhere else and
that is that. This is arrogant, unkind and non-constructive
behaviour. If necessary I am ready to discuss this off-list and
resolve any issues. I am inherently non-confrontation and dislike
the fact that I have to even clarify this. My top priority is
always to find common grounds.
I am almost never frustrated by discussions on the Emacs development
mailing list or in bug reports. The tone is at best productive, at
worst lethargic. This thread is an exception, which is very sad to
see. I implore you once more to consider the GNU Kind Communication
Guidelines and try to foster a productive and positive atmosphere.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 13:59:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 09:59:49 2022 Received: from localhost ([127.0.0.1]:46876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oqEHU-0005f1-QS for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 09:59:49 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:36800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oqEHS-0005dv-3n for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 09:59:47 -0400 Received: by mail-wm1-f49.google.com with SMTP id c3-20020a1c3503000000b003bd21e3dd7aso1354171wma.1 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 06:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=c+gtgLx7+FM25kMavdsdyEKPs4qpG3svZJ0epApx19Y=; b=aL7K7IvOBFn3vTVHHNC5NpBQgJA7WQ9QfkKBZc060Jy1aRY8j4kTFIy4r6t/k/m2l+ SAZuUB8ITlv4cWmHWSgeuUX7wVMF6tw8Zjd7rC1h0CP5/B1ure/dy71wf0KP0/41DSNY 10PUekrMwhtNdG7hqFQ5HZxqY+/0dOw/FZ7clttHmPjxuZbcXJyG3wN+Kwz/qNv894hd goM4L4FamNDZqq5a/tsggiGJVxVENPVrm0lT0+wQ/fp84Omgl+lJYMYX4cH1nYjNYXMl KfsAhq2cKXscL9rmzrwgSwMFue4RtOMT103XMMXNzqZxKywVQuQW3tjKy70mQa+RWGKz dmhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=c+gtgLx7+FM25kMavdsdyEKPs4qpG3svZJ0epApx19Y=; b=jA9yifs21r6C49FpS3n+1b9G+/OZ6ykepNIQ7FasgACwaXC3AjILhlR0+9RuQ9X6SL u7iyW0qLRpnZ+jT5bbZHRxvDYHVtmwBNYUAK6m6X7M9mvcwfzMdPjLKV685PeD6DKUHS 0rXdaVKj7lUuLA9chnnmV88zdMKTZdT3XuY85YK0vq+9DKjYk4Pd/0M420NeBNhsAEgB chcdksKNYKbpDnr7MbKcGs3uFlleye06UF4FDIvi4sLgDj3MYQsPnsrhgPXEoW4y3pVB I/8aB36WJ/s/NtHrsIoNkRMs8te8q1NKYFB16wcrzv/rK0yi0W9rkRbW9KYCM/qSfhe5 76Sw== X-Gm-Message-State: ACrzQf147eB3XtRA7MAVtb3FoIT/JBbQtYOa1TBN+RJV1g9nZ+24VGi2 NrJiilFSmh5wxTJdvx33+WU= X-Google-Smtp-Source: AMsMyM73/fW+z2EwJD0t/61PriZArr5Obt9SHJ/SHbND+4C64oafQ7zKOVBSbY+iSWDWxXVVTEcfzw== X-Received: by 2002:a05:600c:3550:b0:3cf:4c20:5856 with SMTP id i16-20020a05600c355000b003cf4c205856mr15911295wmq.188.1667397579806; Wed, 02 Nov 2022 06:59:39 -0700 (PDT) Received: from krug ([87.196.80.27]) by smtp.gmail.com with ESMTPSA id b6-20020adfee86000000b0023677fd2657sm12931313wro.52.2022.11.02.06.59.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 06:59:39 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87r0ylafdl.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 02 Nov 2022 09:13:10 +0000") References: <87sfj8umwb.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN> <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Wed, 02 Nov 2022 14:00:50 +0000 Message-ID: <87cza5sbfx.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Philip Kaludercic <philipk@HIDDEN> writes: > Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > >> Philip Kaludercic <philipk@HIDDEN> writes: >> >>>> 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'. >> >> No. It couldn't. The error is there to show you among other things >> that the LSP connection isn't being shut down correctly, which is not >> something to paper over. And even if you did paper over the error, you >> would break eglot-autoshutdown. I've explained that at least 3 times >> already in the beginning of this discussion. > > That was not my concern, my concern was that project-kill-buffer > broke. I continue to not see a reason why project.el should be > considered broken because of this, and not jsonrpc/eglot. It was always broken since the way it was created. Eglot's precedes it, I've also explained this. You can't kill a internal hidden buffer just because you can see it anymore than you unintern some "--" symbol in obarray simply because you can see it and don't like its inelegant name, or you think it's taking too much RAM. I can't really explain this any other way. > This is probably best solved by reading code. Can you point me to a few > functions/section/etc. that would help me clarify the situation. > I haven't made up my mind, I am just trying to understand all > perspectives, and get a better overview over the issue. OK, one last time. First, the above principle of encapsulation has nothing to do with LSP or Eglot or Jsonrpc. Specifically in Eglot, as I already explained, eglot.el and jsonrpc.el colaborate so that jsonrpc.el holds a network process to communicate with the LSP server. It uses a buffer for more convenient and efficient parsing of messages. That buffer is out of bounds for Eglot (and anyone else). Eglot doesn't know or care that a buffer is being used, it only actuate on the handle using operations of jsonrpc.el's API. According to user options, Eglot provides controlled shutdown and reconnection using these operations. All of this has worked for a long time and predates project.el's buffer collection/killing/switching logic. If you or some Lisp package finds and destroys the hidden implementation detail, all the above is broken. Therefore packages like project.el that do it are buggy in that regard.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 11:31:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 07:31:28 2022
Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oqBxw-0001F8-6O
for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 07:31:28 -0400
Received: from mout01.posteo.de ([185.67.36.65]:52937)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <philipk@HIDDEN>) id 1oqBxu-0001Et-Ub
for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 07:31:27 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 29DE6240028
for <58839 <at> debbugs.gnu.org>; Wed, 2 Nov 2022 12:31:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1667388681; bh=5/Ac3PgPkgBFNQ25ePngB+QFUx3mdYx09nb3tUzp/E4=;
h=From:To:Cc:Subject:Autocrypt:Date:From;
b=D2pq4ewm43qJhfmhshhVeiLRhtzoAPot6mPht1mgpswURcsV5RNBmp22fbjSmwKHb
oBJ+iyNEXGSu5e3oD3C8MMECWoGzVjAwn1GlnWrXRXJSWhrA2iy7VhXrNkO4wpJfgX
pJjDb9DRdbas+7nfrvVvxRQV5Q1oH5txqKc/D7/4kuJm/5212A30UG1/diiS6mYTk1
YxkqmSLkDJ5OnJ0HdraGZBlFM/ahoQGDQYD/yReHGsJ408kYAsk3o2hvlV3XbW7Egs
aExo4gTocy/rTuKQqMGxvLye1h2wYs2xM/jtj4zXF23NJ38fEkZFZMfNSm3mW67CRC
xVrMgg0IkKI4w==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4N2Pps73CPz6tn7;
Wed, 2 Nov 2022 12:31:17 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <87iljxsmx9.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 09:52:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
<87h6zihq3q.fsf@HIDDEN>
<CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
<877d0ehlnb.fsf@HIDDEN>
<CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
<87edumg4fd.fsf@HIDDEN>
<CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
<874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
<87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
<877d0dbwbu.fsf@HIDDEN> <87r0ylsq7o.fsf@HIDDEN>
<87v8nxafoz.fsf@HIDDEN> <87iljxsmx9.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 11:31:11 +0000
Message-ID: <871qqltwxs.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>>> That way you still get your mini-language, you get a much faster version
>>> of it, and you don't force your mini-language to other people who prefer
>>> just typing plain old Elisp.
>>
>> That is not the case to begin with, as the "mini-language" is just a
>> super-set of Emacs Lisp, seeing as any function is a legal word of the
>> language. As I have said before, it just makes it easier to write
>> common operations like matching buffer names or major modes.
>
> That's not what a super-set is. A super-set language is C++ to C,
> because C++ can compile (almost any) C program. The mini-language is a
> DSL. In my opinion, one that brings very few advantages, but there's no
> accounting for taste. So the common way to do DSL's in Elisp is use the
> approach I provided. You make them more useful, and you don't force
> people to use them.
Let B be the set of S-Expressions that `buffer-match-p' handles, and F
be the set of S-Expressions that satisfy `functionp'. We see that
B =E2=88=96 F =E2=89=A0 =E2=88=85
as for any foo, (major-mode . foo) =E2=88=88 B, but (major-mode . foo) =E2=
=88=89 F. We
see that
F =E2=88=96 B =3D =E2=88=85
as every function (per `functionp') is a valid `buffer-match-p'
predicate. Hence we conclude that B =E2=8A=8B F (strict superset). =
=E2=88=8E
>> be a special symbol, so I would like to avoid the possibility of this
>> leading to issues that hack to be back-hacked at some point in the
>> future.
>>
>> But this is just a matter of personal style. I have seen you write
>> documentations strings like "[...] This docstring appeases checkdoc,
>> that's all."
>
> Ahaha, that was just a joke. Keep documenting all your functions,
> you're very right to do so. Trust me, don't make defvar's for
> (make-symbol). Noone does this: it's just cruft.
Again, see the other bug report, the code I pasted in this thread was
just a sketch.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 09:51:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 05:51:48 2022 Received: from localhost ([127.0.0.1]:44940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oqAPT-0004gO-I5 for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:51:48 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:38594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oqAPS-0004g6-93 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:51:46 -0400 Received: by mail-wr1-f51.google.com with SMTP id a14so23693693wru.5 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 02:51:46 -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=DQxZ+TIJnmlG5FyUAsgo/jcWJ7hSylBkCT7OzA+18K4=; b=CMl8qqjoYrAe0TYZ8aT7Uzh25IAtV7PRJfvbRvJckBC/f9KD1y2brQYCKHV5v3qjJi XJnYUba/+0HoNyrowI36rVw3uniNY5BiZBMmS1BBuhx+aKFt4gstJ33KH0SJ7yGeTy+o ty1zvkuopqrW1S4eVqspEVIO3MCrwQ44YkIFhZeZse0Cf5njZ5d73ZdCHM1GMBjsF5jD 4YInJ4JOetduzVLu9hVVeSgvbS7fV6WGh3Xah1IYHllK4SpWi1O/fwH0lLdk7RvqpBZz SrMncKifX8ywHTyGRccyk1XmS86ikUPe9cWrXagiOL9RyJt6sspG4PZeui4k1Wq8+PHn FmAw== 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=DQxZ+TIJnmlG5FyUAsgo/jcWJ7hSylBkCT7OzA+18K4=; b=NpJCpqFi6/VXKFU0sogMpzw48Y2krzXW0+muw9XfOKquaPt4F5bT8etByE0dzyGU51 6DT8dUArv7IJkZAs9z1iomKTfsi5wHRfntSw1smoxMAypep01xuAl0bmv3b0Z4IN4lev Bvli3vAJDbLq7sisR3Mg7YemRyxLhmiHuDfHNhR0PDQnKd2DrjCjeEP2pq6poa9R0/vl vxl5I/1ZDgvbI3tdDLP1XVhJd2eNSl7TmOs4mnNlj2d5jE+oJTMLAVlbu/jEa/fUZudR OC18sdl2GwLHfuL3NjvXc208mY824mHI7ooBeaNv6+x+Jbx9jjbOLDqVXQmtGIfmk+FO kTcg== X-Gm-Message-State: ACrzQf0h7OfTOqBnwt3fzns+3UEpvB4AOkoU1J/FdcmWEUqEoO9m2qlr CwEjo3uculNzoXFJPZaY7RNtu/en4BA= X-Google-Smtp-Source: AMsMyM7ErRsvKilVFiZdVq4nREd7oE43kw+zWhg24EwNpD+bUhMgpQ8ZruOXlCVjtVKhkZkWZrN44Q== X-Received: by 2002:adf:ef4e:0:b0:236:6608:f6ce with SMTP id c14-20020adfef4e000000b002366608f6cemr14467325wrp.85.1667382700005; Wed, 02 Nov 2022 02:51:40 -0700 (PDT) Received: from krug (87-196-81-36.net.novis.pt. [87.196.81.36]) by smtp.gmail.com with ESMTPSA id j19-20020a05600c1c1300b003a8434530bbsm1621429wms.13.2022.11.02.02.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 02:51:39 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87v8nxafoz.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 02 Nov 2022 09:06:20 +0000") References: <87sfj8umwb.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> <87edumg4fd.fsf@HIDDEN> <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN> <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN> <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN> <877d0dbwbu.fsf@HIDDEN> <87r0ylsq7o.fsf@HIDDEN> <87v8nxafoz.fsf@HIDDEN> Date: Wed, 02 Nov 2022 09:52:50 +0000 Message-ID: <87iljxsmx9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Philip Kaludercic <philipk@HIDDEN> writes: >> But then you're throwing away the benefits of compilation. But my >> suggestion is for you to get rid of "buffer-match-p". Rather, make a >> 'buffer-matcher' that does the compilation, and then place the return >> value of that, which is a plain old (possibly very fast, if compiled) >> function object in the display-buffer-alist variables and everywhere >> where you can put functions. > > I see, but I don't agree. My main objection here is that the conditions > aren't introspectable (e.g. when using ECI) any more and that it all > becomes more verbose. If you want introspection, i.e. see the translated Elisp code when inspecting the value of display-buffer-alist, then pass another argument to buffer-matcher which makes it return an uncompiled function. Furthermore, as debugging goes, the buffer-matcher idea is much better: if the user does a mistake in his mini-language program, that mistake can be caught when buffer-matcher is called, i.e. during her init. Not when display-buffer-alist is about to run the program. And if your mini-language ever evolves, you can also issue warnings at this point. This is what compilation and compilers have always existed for. Lisp gives you this power in a few lines (something which takes a lot of hard in other languages). >> That way you still get your mini-language, you get a much faster version >> of it, and you don't force your mini-language to other people who prefer >> just typing plain old Elisp. > > That is not the case to begin with, as the "mini-language" is just a > super-set of Emacs Lisp, seeing as any function is a legal word of the > language. As I have said before, it just makes it easier to write > common operations like matching buffer names or major modes. That's not what a super-set is. A super-set language is C++ to C, because C++ can compile (almost any) C program. The mini-language is a DSL. In my opinion, one that brings very few advantages, but there's no accounting for taste. So the common way to do DSL's in Elisp is use the approach I provided. You make them more useful, and you don't force people to use them. > I have not much elese to say on the issue here, that hasn't already been > said. If you think it is such a mistake, please report a bug or post on > emacs-devel and we can clarify the issue there. OK. It's not so much a mistake as lost opportunity to make a more reusable, less britlle piece of software using less code, less docstrings, less manual writing, etc. Cuts down on the mental overload, potentially teaches some people Elisp instead of mini-language, and reduces CPU usage and laptop battery time. >>> This is currently not the case, but if the language extended in the >>> future, there is the possibility that naming conflicts could arise. I >>> am just following the same principle used when writing macros that >>> avoids name capturing. >> >> You don't need to cargo cult that principle blindly. This kind of macro >> hygiene you are talking about is for macros that take arbitrary lisp >> forms, which is not the case of the mini-language. If it ever is, add >> the hygiene then and likely not in a top-level defvar. > > I don't see any disadvantage from following best practices, even if it > is not immediately relevant. This is not a best practice, really it's not. MAKE-SYMBOL and GENSYM are for macro that take forms hygiene: this is simply not that case. > be a special symbol, so I would like to avoid the possibility of this > leading to issues that hack to be back-hacked at some point in the > future. > > But this is just a matter of personal style. I have seen you write > documentations strings like "[...] This docstring appeases checkdoc, > that's all." Ahaha, that was just a joke. Keep documenting all your functions, you're very right to do so. Trust me, don't make defvar's for (make-symbol). Noone does this: it's just cruft.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 09:13:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 05:13:22 2022 Received: from localhost ([127.0.0.1]:44927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq9oH-0003dR-Vd for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:13:22 -0400 Received: from mout01.posteo.de ([185.67.36.65]:46817) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oq9oG-0003dD-2v for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:13:20 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5ECED240029 for <58839 <at> debbugs.gnu.org>; Wed, 2 Nov 2022 10:13:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667380394; bh=GTE+qtj3jpAdAmC0k1Am+bbj+3c9F/InoY0V4DVdBR4=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=BBB1t00VfwcuKkAM90aPmHxr7DRmir1eY2jmjaLJ8QUgJYdkf4nn6usRY7huoMags zrhQ/WtMEPk/zkw5RwMXbR+J193rNXnN4wCo7QcCX/UTlQI4rSUZyGXIN1rKlGY3aK ttN+Ay7y75sRadQLITD2u/bWtJM1Z/094oJjCLcjB7XQwM3GvP5wJJuOyZKtpjC1ZE VMxnhb3thRerlq6kbsxKLdAV02hz1IaENaQI5WFa6HPUyHC99Ni4DpBHl89XoTat7t vrCyVtC/GBn3cST0JvZ7qE3/g8bLnp1mcFetTIVBAW8obNou82jI6/gCfFylwyQGw7 /lfcwXWI2JUPg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2LlV4LVRz9rxV; Wed, 2 Nov 2022 10:13:10 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87mt99spsk.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 08:50:51 +0000") References: <87sfj8umwb.fsf@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN> <87mt99spsk.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Wed, 02 Nov 2022 09:13:10 +0000 Message-ID: <87r0ylafdl.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Philip Kaludercic <philipk@HIDDEN> writes: > >>> 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'. > > No. It couldn't. The error is there to show you among other things > that the LSP connection isn't being shut down correctly, which is not > something to paper over. And even if you did paper over the error, you > would break eglot-autoshutdown. I've explained that at least 3 times > already in the beginning of this discussion. That was not my concern, my concern was that project-kill-buffer broke. I continue to not see a reason why project.el should be considered broken because of this, and not jsonrpc/eglot. To be fair, I am not as familiar with LSP as you are, so there might be a technical reason why this is the case, but without something like that, you appear to be privileging an arbitrary perspective, supposedly because you are the maintainer of these packages. This is probably best solved by reading code. Can you point me to a few functions/section/etc. that would help me clarify the situation. >>> 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. > > I just said that becasue you at one point did suggested the > opt-in approach=20 > > I have to admit that I am more and more inclined to make the list a > opt-in thing, where we explicitly mark those major modes that are tied > to a project. The key word here is "more and more inclined". > But of course it's OK to change one's mind back and forth. I haven't made up my mind, I am just trying to understand all perspectives, and get a better overview over the issue.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 09:06:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 05:06:37 2022 Received: from localhost ([127.0.0.1]:44915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq9hl-0003Td-4h for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:06:37 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57853) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oq9hi-0003TP-BP for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:06:35 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id AA20B240107 for <58839 <at> debbugs.gnu.org>; Wed, 2 Nov 2022 10:06:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667379988; bh=D/MMZN0u3wA0q1CiPMdlRRfIgDygp0wIW5mRrLBnn9s=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=UJeZGbz/TQBvwU57snwHdZ8Z8rGh57ej5N8LNVPxsmzc6AGY66Fn7W/q77gjxh1Pr V98sOnsRa3ctKtELKeH16RhwFtqlrxD6IGtZTpY5TzzXxkPHgFCDC5+qzZHTMyHfTw Lql1t1emhUUqKOYrLTJcoaNYphuU9iWV5tGRfFx6dn2EniCHfZ2I6Rf4dN94L9jwGM do1oatojzOFCq74am3LWQyezs5abuNlkEs/rJspWvOO7tvFq3ZWFb1IvTfOTdCzkEl Zut6DsLUT2Pb0YqutLxTsPiO6kaqfdLZcJw2qYe8mlOj+WvJ3mbTmWg0JS4g2jTnIT xfzhG6CBX9RBg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2Lbk4D3Cz6tm6; Wed, 2 Nov 2022 10:06:25 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87r0ylsq7o.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 08:41:47 +0000") References: <87sfj8umwb.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> <87edumg4fd.fsf@HIDDEN> <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN> <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN> <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN> <877d0dbwbu.fsf@HIDDEN> <87r0ylsq7o.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Wed, 02 Nov 2022 09:06:20 +0000 Message-ID: <87v8nxafoz.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Philip Kaludercic <philipk@HIDDEN> writes: > >>> I couldn't figure out where this argument arise or who should provides >>> it (the condition?). It wasn't clear. At any rate, if you understand >>> this you can probably re-add it and I'm sure it won't make any >>> difference to the time. >> >> See `display-buffer-assq-regexp' in window.el. > > Sorry, I'm not following. Anyway, as I said, this seems to be a detail: > feel free to add back arg wherever it is needed. I just meant to give an example where and how the argument is used. >>> More importantly, you're >>> forcing the byte-compilation process to run every one of those 100000 >>> repetitions, which is not something we want to measure: the point of any >>> code compilation is to do it once and then reuse the results of >>> compilation many times. >> >> Exactly, but if the byte-compilation would take place in buffer-match-p, >> then the measurement is relevant. > > But then you're throwing away the benefits of compilation. But my > suggestion is for you to get rid of "buffer-match-p". Rather, make a > 'buffer-matcher' that does the compilation, and then place the return > value of that, which is a plain old (possibly very fast, if compiled) > function object in the display-buffer-alist variables and everywhere > where you can put functions. I see, but I don't agree. My main objection here is that the conditions aren't introspectable (e.g. when using ECI) any more and that it all becomes more verbose. > That way you still get your mini-language, you get a much faster version > of it, and you don't force your mini-language to other people who prefer > just typing plain old Elisp. That is not the case to begin with, as the "mini-language" is just a super-set of Emacs Lisp, seeing as any function is a legal word of the language. As I have said before, it just makes it easier to write common operations like matching buffer names or major modes. >>> (and I'm still confused by the purpose of the hash table usage) >> >> The rationale is the same as for regular expressions in the core. They >> are also compiled and stored, to avoid the need for them to be >> interpreted over and over again. >> >> This should all be explained in the bug report I pointed you to, and >> where this discussion should continue. > > Well, I think you're overcomplicating this. If you insulate > display-buffer-alist from the mini-language (i.e. you keep it the way it > was), then you don't need this hash table, and you can still use the > mini-language. > > (add-to-list 'display-buffer-alist > `(,(philips-mini-language-buffer-matcher > '(and (mode . x) (or (not (and "123"))))) > . display-buffer-in-side-window)) > > Again: you keep your mini-language and you can suggest people use > philips-mini-language-buffer-matcher in many other library APIs in > Emacs, not just window.el, but without needing to ever touch those > libraries. > > It's a much more modular design, less impositive, much smaller and much > faster. I have not much elese to say on the issue here, that hasn't already been said. If you think it is such a mistake, please report a bug or post on emacs-devel and we can clarify the issue there. >> This is currently not the case, but if the language extended in the >> future, there is the possibility that naming conflicts could arise. I >> am just following the same principle used when writing macros that >> avoids name capturing. > > You don't need to cargo cult that principle blindly. This kind of macro > hygiene you are talking about is for macros that take arbitrary lisp > forms, which is not the case of the mini-language. If it ever is, add > the hygiene then and likely not in a top-level defvar. I don't see any disadvantage from following best practices, even if it is not immediately relevant. There is no reason why `buffer' ought to be a special symbol, so I would like to avoid the possibility of this leading to issues that hack to be back-hacked at some point in the future. But this is just a matter of personal style. I have seen you write documentations strings like "[...] This docstring appeases checkdoc, that's all.", while I insist on documenting every function I commit, even if I am the only one who uses the package. We just have different principles. > Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:49:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 04:49:47 2022 Received: from localhost ([127.0.0.1]:44903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq9RS-00034L-Qz for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:49:47 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:36541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oq9RR-000349-Sp for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:49:46 -0400 Received: by mail-wr1-f46.google.com with SMTP id j15so23453633wrq.3 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 01:49:45 -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=UqO6Eoe2NqDqH4iJ3U7JsD0VWa0ZGpu0DdddY4sDWzU=; b=CZK0cHgoBV49hOJJXV9w7GkprbdCWuhWCe93b8OH8YO2g4vZtPZacW73fuy4SiQAGU KrmiT4ujgtlMYS3XQGfXEO6CMqO7qAMSRDUCIRqd9D98kLTiRDDoem6Mf2KdBA7YCttD dkYA+EvnJ+2VyTOteLHmTaOtXmB5fXyHA7JiyKjHHszVxh6uNbep9nTRB+SriLzl7K2d W1HA80oTwO3xjmbBRk5GQALoeaJE8YeJk0D/VI/BoV9W/0e97yIFeTWS73bRMTcQfzyI CKOZdyXH0A0ECG8a5MNawh/NhQAD7yepRYJk5kEqXPMSIohHp9sWO4+JvmHuVyfFIl6x xl9A== 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=UqO6Eoe2NqDqH4iJ3U7JsD0VWa0ZGpu0DdddY4sDWzU=; b=mc03ljS5WcREXMHWgPsn+fLpi+dNqzYlyEGXVEj/G52AanPkPZTNAJiiyJ0TRJbEHf na8wyhRthvAZytXSFHE+5FFw68HpWorCxDM2p8tpOCKD9ConPzX74RohHjEp6/qwMLbN DCKIr3SIoIOVhB7fqOMqV2g2ht3qK/P8XZcRwu9ryraY68RUEPUro6NHn7a69B7UIC1D /K4AyZ9faxnrPMXLze953BtTPWbncjEmrfZOENIvxje3ijEOEUSFLklzJN8FakBvbaET ipXXMtsvf9Dv6d+TwPQN2ZabXcWcRAPSQ6EYHGpbr4HR+dJjblbV9mYTlNFX98fbpi1t pYxQ== X-Gm-Message-State: ACrzQf0pZhcSlFE6x9VrrGhWSuHXsaKihsOpD4V6JxIC+/aRq5ThleFd RvY/lrjSctlXjjUHZjUeGpc= X-Google-Smtp-Source: AMsMyM7L+n65U9ydEV/2SynYN9TFIGPjpABUeeA3mC536MYqgDYZtHTWLz60z7nQje7s4/a0Aeib8Q== X-Received: by 2002:adf:ff90:0:b0:236:cb5d:4824 with SMTP id j16-20020adfff90000000b00236cb5d4824mr9642927wrr.718.1667378980204; Wed, 02 Nov 2022 01:49:40 -0700 (PDT) Received: from krug (87-196-81-36.net.novis.pt. [87.196.81.36]) by smtp.gmail.com with ESMTPSA id dn12-20020a05600c654c00b003cf537ec2efsm1490437wmb.36.2022.11.02.01.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 01:49:39 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <8735b1bvnz.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 02 Nov 2022 08:36:00 +0000") References: <87sfj8umwb.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN> Date: Wed, 02 Nov 2022 08:50:51 +0000 Message-ID: <87mt99spsk.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Philip Kaludercic <philipk@HIDDEN> writes: >> Not sure. This started has a report of hidden buffer being incorrectly >> killed by project.el. > > 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'. No. It couldn't. The error is there to show you among other things that the LSP connection isn't being shut down correctly, which is not something to paper over. And even if you did paper over the error, you would break eglot-autoshutdown. I've explained that at least 3 times already in the beginning of this discussion. >> 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. I just said that becasue you at one point did suggested the opt-in approach I have to admit that I am more and more inclined to make the list a opt-in thing, where we explicitly mark those major modes that are tied to a project. But of course it's OK to change one's mind back and forth.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:40:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 04:40:47 2022
Received: from localhost ([127.0.0.1]:44898 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oq9Ik-0002ok-Nq
for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:40:47 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:41793)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1oq9If-0002oO-LC
for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:40:44 -0400
Received: by mail-wr1-f46.google.com with SMTP id w14so23391001wru.8
for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 01:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding: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=4YZbzUoBCcHCiWBRI/Eho7eyp9jmpwGDzJ+1R1MOkeE=;
b=dy4K/L/HN1FQinMpf3Sdx50ISUgEAroMtl5Kre+mEygfPW38UvKP4qdVNR7foIMxLL
UC3UrMfgCSIdzjCmykQVzzU/rMCo6Ht1QqC9vr7RB7+XpIF/TOuSQAB5CdmJvVoIubbi
/PObSNcY+3tQKTnjnqD8osH+I800WFR6rmcNo5dwxX6xMgwF3oNLRT34txvgAfS0+Sy7
BPRPALMvQx3ni3wi+CMPskPyhb72Ol9pK5T5mb/Sj9T9+0vgrXFAidpJ1+v0Cd9j0njL
TPc5XfUOOLoRhTZXtpzDmYzs7g2kzaizi7HL8SmgPCAAbLrwdNcnxhrX3Mdn2JszZzRM
6MIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding: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=4YZbzUoBCcHCiWBRI/Eho7eyp9jmpwGDzJ+1R1MOkeE=;
b=GTXBzRRYHP/RtJMLZgmXhAHGuuo6TGpPttQIwoR0nHe+arjolOqmATctdGLbnwzIBN
3Q9qLYmJy9XtCvZIhyC447q6Bk4yrP4a+5Ns9b1IVZMCApMSbXncV7hEk5GEGAr3tCxu
nogRMXobEPDpDqw4K4IoqRBjhuNzY0QzUKgwRTdXzmDxV0JqO/obOBrIlMc/uw55rYDU
N+pc/hGJ7W8mpQeXM/8ALy0G9Yq3cDyU9NhhnI7HcI+Bu/PTTrG+r46IWVZsf+1tg/0R
2rOpHG8etRARS4Bf9AzmqyIySOK6vR8zSc/9QxA3bDlvuxHG6tlaK055PCFwTo4o36hS
gTYw==
X-Gm-Message-State: ACrzQf1AKx5woKRFoiYn+klxPOwuyzKviXLO4BjHxuBfj+QZm0MwsGAu
D3aicUjSiCdg+X8qIP5HmpJ6h/Px59s=
X-Google-Smtp-Source: AMsMyM4CYP/MMyboTbBr9y3T8bITmuu+EbkxiItF34oKR+XOaknxjUmV4V2vEqMmxsGx0IBtBcQKlA==
X-Received: by 2002:a5d:4944:0:b0:236:7f32:1ad5 with SMTP id
r4-20020a5d4944000000b002367f321ad5mr14399230wrs.377.1667378435446;
Wed, 02 Nov 2022 01:40:35 -0700 (PDT)
Received: from krug (87-196-81-36.net.novis.pt. [87.196.81.36])
by smtp.gmail.com with ESMTPSA id
bo29-20020a056000069d00b0022eafed36ebsm12474562wrb.73.2022.11.02.01.40.34
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 02 Nov 2022 01:40:34 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <877d0dbwbu.fsf@HIDDEN> (Philip Kaludercic's message of "Wed,
02 Nov 2022 08:21:41 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
<837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
<87h6zihq3q.fsf@HIDDEN>
<CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
<877d0ehlnb.fsf@HIDDEN>
<CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
<87edumg4fd.fsf@HIDDEN>
<CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
<874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
<87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
<877d0dbwbu.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 08:41:47 +0000
Message-ID: <87r0ylsq7o.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Philip Kaludercic <philipk@HIDDEN> writes:
>> I couldn't figure out where this argument arise or who should provides
>> it (the condition?). It wasn't clear. At any rate, if you understand
>> this you can probably re-add it and I'm sure it won't make any
>> difference to the time.
>
> See `display-buffer-assq-regexp' in window.el.
Sorry, I'm not following. Anyway, as I said, this seems to be a detail:
feel free to add back arg wherever it is needed.
>> More importantly, you're
>> forcing the byte-compilation process to run every one of those 100000
>> repetitions, which is not something we want to measure: the point of any
>> code compilation is to do it once and then reuse the results of
>> compilation many times.
>
> Exactly, but if the byte-compilation would take place in buffer-match-p,
> then the measurement is relevant.
But then you're throwing away the benefits of compilation. But my
suggestion is for you to get rid of "buffer-match-p". Rather, make a
'buffer-matcher' that does the compilation, and then place the return
value of that, which is a plain old (possibly very fast, if compiled)
function object in the display-buffer-alist variables and everywhere
where you can put functions.
That way you still get your mini-language, you get a much faster version
of it, and you don't force your mini-language to other people who prefer
just typing plain old Elisp.
>> (and I'm still confused by the purpose of the hash table usage)
>
> The rationale is the same as for regular expressions in the core. They
> are also compiled and stored, to avoid the need for them to be
> interpreted over and over again.
>
> This should all be explained in the bug report I pointed you to, and
> where this discussion should continue.
Well, I think you're overcomplicating this. If you insulate
display-buffer-alist from the mini-language (i.e. you keep it the way it
was), then you don't need this hash table, and you can still use the
mini-language.
(add-to-list 'display-buffer-alist
`(,(philips-mini-language-buffer-matcher
'(and (mode . x) (or (not (and "123")))))
. display-buffer-in-side-window))
Again: you keep your mini-language and you can suggest people use
philips-mini-language-buffer-matcher in many other library APIs in
Emacs, not just window.el, but without needing to ever touch those
libraries.
It's a much more modular design, less impositive, much smaller and much
faster.
> This is currently not the case, but if the language extended in the
> future, there is the possibility that naming conflicts could arise. I
> am just following the same principle used when writing macros that
> avoids name capturing.
You don't need to cargo cult that principle blindly. This kind of macro
hygiene you are talking about is for macros that take arbitrary lisp
forms, which is not the case of the mini-language. If it ever is, add
the hygiene then and likely not in a top-level defvar.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:36:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 04:36:12 2022 Received: from localhost ([127.0.0.1]:44891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq9EJ-0002iH-VS for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:36:12 -0400 Received: from mout02.posteo.de ([185.67.36.66]:48461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oq9EI-0002hy-2z for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:36:10 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 46C7D240106 for <58839 <at> 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== 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) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87a659u7vo.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 07:34:51 +0000") References: <87sfj8umwb.fsf@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Wed, 02 Nov 2022 08:36:00 +0000 Message-ID: <8735b1bvnz.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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 <joaotavora@HIDDEN> writes: > Dmitry Gutov <dgutov@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:21:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 04:21:51 2022 Received: from localhost ([127.0.0.1]:44867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq90Q-0002Kf-T6 for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:21:51 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57453) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oq90O-0002KS-NL for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:21:49 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E7A69240106 for <58839 <at> debbugs.gnu.org>; Wed, 2 Nov 2022 09:21:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667377302; bh=8rGBLeQTatMLtFtWVAm9WzySkujMKY8TW358ZcjpmpY=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Dw2Bc27/VA8pE1DGV/Izx05CYu1FUszuE8XkW3xLF5OzP1S+e0T2abliNi3F4CjaS eIPEbpICd2ujMkJIkXXAwp1v1WNAa8W1KGYT8e8zTFBFn4WqKzkaA39A8Ui2vLgaup SwvyjmkbjqDQi/SJcHMwVRGVWSqYI5a9YKxQMmonjffA8Sd5D9VA8D2MoDcfn7pP7E 76yYAG1OreytGY5NnQ5j5spKGDCaBHcJ7Ap5qk/ffq0LTb/ta8YoWmGDzeAVI5Lwqr buCGe19DYtzAGPnrby/Q0sBBpoF7lZe6spoh1umZOmuuS9sOvnRgPlXXA12eg6hbMe FQJ/6sI1NdFgg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2Kc60nB9z6tmy; Wed, 2 Nov 2022 09:21:41 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <871qqlu79b.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 07:48:16 +0000") References: <87sfj8umwb.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> <87edumg4fd.fsf@HIDDEN> <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN> <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN> <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Wed, 02 Nov 2022 08:21:41 +0000 Message-ID: <877d0dbwbu.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Philip Kaludercic <philipk@HIDDEN> writes: > >> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: >> >>> Philip Kaludercic <philipk@HIDDEN> writes: >>> >>>>> Yes, do that, but use byte-compile instead, not eval. >>>> I have tried both, and it doesn't appear to be a particular advantage >>>> one way or another. That being said, this approach is *a lot* faster, >>>> to the point that I first assumed it was broken: >>> >>> Yes, this approach is always going to be much faster than the "naive" >>> approach. Now I've taken your code as a starting point, simplified it, >>> and I get a reasonable/typical 3.5x speedup when I use a >>> byte-compilation strategy, so one of us isn't measuring >>> >>> ```elisp >>> (defun translate-buffer-condition-1 (condition) >>> (pcase-exhaustive condition >>> ((or 't 'nil) >>> condition) >>> ((pred stringp) >>> `(string-match-p ,condition (buffer-name buffer))) >>> ((pred functionp) >>> `(,condition buffer)) >> >> This would break the current behaviour, because `buffer-match-p' >> requires the function be called with an additional argument if possible. >> >> This is fundamental for `display-buffer-alist' to work. > > I couldn't figure out where this argument arise or who should provides > it (the condition?). It wasn't clear. At any rate, if you understand > this you can probably re-add it and I'm sure it won't make any > difference to the time. See `display-buffer-assq-regexp' in window.el. >>> (`(major-mode . ,mode) >>> `(eq (buffer-local-value 'major-mode buffer) >>> ',mode)) >>> (`(derived-mode . ,mode) >>> `(provided-mode-derived-p >>> (buffer-local-value 'major-mode buffer) >>> ',mode)) >>> (`(not . ,cond) >>> `(not ,(translate-buffer-condition-1 cond))) >>> (`(or . ,conds) >>> `(or ,@(mapcar #'translate-buffer-condition-1 conds))) >>> (`(and . ,conds) >>> `(and ,@(mapcar #'translate-buffer-condition-1 conds))))) >>> >>> (defun translate-buffer-condition (condition) >>> `(lambda (buffer) ,(translate-buffer-condition-1 condition))) >>> >>> (defvar sample-condition >>> '(and (or buffer-file-name >>> (derived-mode . compilation-mode) >>> (derived-mode . dired-mode) >>> (derived-mode . diff-mode) >>> (derived-mode . comint-mode) >>> (derived-mode . eshell-mode) >>> (derived-mode . change-log-mode)) >>> "\\*.+\\*" >>> (not . "\\` "))) >>> >>> (defvar form (translate-buffer-condition sample-condition)) >>> (defvar compiled (byte-compile form)) >>> >>> (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.397= 404883 3 0.18942550900000032) >>> (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.113651= 836 0 0.0) >>> ``` >>> >>> I couldn't understand the need for a hash table or special symbol vars >>> or what that "arg" was, so I took it out, but it shouldn't make a >>> difference. >> >> The hash table makes a significant different, try evaluating >> >> (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffe= r))) ;; (0.113651836 0 0.0) >> > > You seem to be suggesting to byte-compile a compiled object which is > odd. Did you mean (byte-compile form)?=20=20 Yes, that was a copy-o on my end. > More importantly, you're > forcing the byte-compilation process to run every one of those 100000 > repetitions, which is not something we want to measure: the point of any > code compilation is to do it once and then reuse the results of > compilation many times. Exactly, but if the byte-compilation would take place in buffer-match-p, then the measurement is relevant. > (and I'm still confused by the purpose of the hash table usage) The rationale is the same as for regular expressions in the core. They are also compiled and stored, to avoid the need for them to be interpreted over and over again. This should all be explained in the bug report I pointed you to, and where this discussion should continue. >> The fresh symbols are used to keep the code clean and avoid possible >> naming conflicts. > > Can you explain what naming conflict would arise or how the code I > provided is somehow unclean? This is currently not the case, but if the language extended in the future, there is the possibility that naming conflicts could arise. I am just following the same principle used when writing macros that avoids name capturing.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:47:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 03:47:13 2022 Received: from localhost ([127.0.0.1]:44837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq8Sv-0001Ro-E3 for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:47:13 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:36427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oq8Su-0001Rb-31 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:47:12 -0400 Received: by mail-wr1-f41.google.com with SMTP id j15so23244513wrq.3 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=q54FjQLIrHzW3Kpe3xQQcJI92y2NY2m9psANBUVBLNs=; b=ic3SfF2bu6A6ME3VqaB9im3WLcknwiXv52KTi3nF1xdty0k4Wu/FXQ6lQFwtLVoxoF XWZVROrV0S5dwNBCZKfL3Znllqguh/4OjHot3eFX77Q552IiTSqfamQ4/JuDh054fzMo 4jYDkfJKFE/n4kxbKl5ESIIPyJgwSw+5FckPXIYjwMXxOgM8fj7/k2hSkLfGO7Uh4BE3 YbXM1EWQC8+3/9N0wCodu6trmnBi9nIfNxhDDNTaduYE3JwVkzy5e1yj1ZasKhrZlpJp hs4tGlZHTbYd8vra1tcarA0XD/SqqCKK51fAJZnb2TU8uTz118r3aoZB5dx211d939FD WPtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=q54FjQLIrHzW3Kpe3xQQcJI92y2NY2m9psANBUVBLNs=; b=WWQLJhJvqGSAbdVlCtgstyQAVgvzJ7IRA4hDnoNvzX26noN9Cpf44ngUzAXZAaDIBC pPPIvKtA8Sc7oWvQLTO6ARLFRXvSdXfp8hNH7iZ02UEryQBPYtPA/M0qU08fdHXwv+4P RIDDAEMmVE5IMFZR8gdSEssdjogsw6FSeS+Gm6hQofbtiu1iMvmlwkNgWiYOVeJa+4Zm OK1qP9FT5R9vp9aAjYApZRF80yQsYMsgWiIA4ZRTWeC6LoRRoUEO0+bJsNZkKr1ix7hG aFPfeykZXeCYy2dDmoMCB06vesbsVRMvrnPFW2ree4vzHFFbpld1pn8vaTdPi9k4hPWZ OtNQ== X-Gm-Message-State: ACrzQf2Wp0x5/+/VrUp10ML+jQrE9F8Pm5SGQ2/7YuTzs5ucIaPC47tV L7SK3UZhNsejrVe+BXNca/EgdbbBgCE= X-Google-Smtp-Source: AMsMyM4Js//3hYf9zYTH5+A+o48RSAyNBtIekfxJx3IFFWZfM5+mF4IzF70e8z5PK0wU4iLUNwFC+A== X-Received: by 2002:adf:a45a:0:b0:236:9aa8:e675 with SMTP id e26-20020adfa45a000000b002369aa8e675mr14339829wra.407.1667375225949; Wed, 02 Nov 2022 00:47:05 -0700 (PDT) Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id u8-20020a05600c19c800b003c6f8d30e40sm1145856wmq.31.2022.11.02.00.47.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 00:47:05 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87wn8dbyq1.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 02 Nov 2022 07:29:58 +0000") References: <87sfj8umwb.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> <87edumg4fd.fsf@HIDDEN> <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN> <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN> <87wn8dbyq1.fsf@HIDDEN> Date: Wed, 02 Nov 2022 07:48:16 +0000 Message-ID: <871qqlu79b.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Philip Kaludercic <philipk@HIDDEN> writes: > Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > >> Philip Kaludercic <philipk@HIDDEN> writes: >> >>>> Yes, do that, but use byte-compile instead, not eval. >>> I have tried both, and it doesn't appear to be a particular advantage >>> one way or another. That being said, this approach is *a lot* faster, >>> to the point that I first assumed it was broken: >> >> Yes, this approach is always going to be much faster than the "naive" >> approach. Now I've taken your code as a starting point, simplified it, >> and I get a reasonable/typical 3.5x speedup when I use a >> byte-compilation strategy, so one of us isn't measuring >> >> ```elisp >> (defun translate-buffer-condition-1 (condition) >> (pcase-exhaustive condition >> ((or 't 'nil) >> condition) >> ((pred stringp) >> `(string-match-p ,condition (buffer-name buffer))) >> ((pred functionp) >> `(,condition buffer)) > > This would break the current behaviour, because `buffer-match-p' > requires the function be called with an additional argument if possible. > > This is fundamental for `display-buffer-alist' to work. I couldn't figure out where this argument arise or who should provides it (the condition?). It wasn't clear. At any rate, if you understand this you can probably re-add it and I'm sure it won't make any difference to the time. >> (`(major-mode . ,mode) >> `(eq (buffer-local-value 'major-mode buffer) >> ',mode)) >> (`(derived-mode . ,mode) >> `(provided-mode-derived-p >> (buffer-local-value 'major-mode buffer) >> ',mode)) >> (`(not . ,cond) >> `(not ,(translate-buffer-condition-1 cond))) >> (`(or . ,conds) >> `(or ,@(mapcar #'translate-buffer-condition-1 conds))) >> (`(and . ,conds) >> `(and ,@(mapcar #'translate-buffer-condition-1 conds))))) >> >> (defun translate-buffer-condition (condition) >> `(lambda (buffer) ,(translate-buffer-condition-1 condition))) >> >> (defvar sample-condition >> '(and (or buffer-file-name >> (derived-mode . compilation-mode) >> (derived-mode . dired-mode) >> (derived-mode . diff-mode) >> (derived-mode . comint-mode) >> (derived-mode . eshell-mode) >> (derived-mode . change-log-mode)) >> "\\*.+\\*" >> (not . "\\` "))) >> >> (defvar form (translate-buffer-condition sample-condition)) >> (defvar compiled (byte-compile form)) >> >> (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.3974= 04883 3 0.18942550900000032) >> (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.1136518= 36 0 0.0) >> ``` >> >> I couldn't understand the need for a hash table or special symbol vars >> or what that "arg" was, so I took it out, but it shouldn't make a >> difference. > > The hash table makes a significant different, try evaluating > > (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffer= ))) ;; (0.113651836 0 0.0) > You seem to be suggesting to byte-compile a compiled object which is odd. Did you mean (byte-compile form)? More importantly, you're forcing the byte-compilation process to run every one of those 100000 repetitions, which is not something we want to measure: the point of any code compilation is to do it once and then reuse the results of compilation many times. (and I'm still confused by the purpose of the hash table usage) > The fresh symbols are used to keep the code clean and avoid possible > naming conflicts. Can you explain what naming conflict would arise or how the code I provided is somehow unclean?
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:39:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 03:39:07 2022 Received: from localhost ([127.0.0.1]:44831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq8L5-0001Fd-DD for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:39:07 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:44790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oq8L3-0001F8-6Z for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:39:05 -0400 Received: by mail-wr1-f49.google.com with SMTP id v1so23194429wrt.11 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=oBB1pjuGq5DBJTXzI00pR3+doKqX60PeMJxwMnGK8Zs=; b=mOfsDMq6b/6OyKlNquyeAiSqkld4CHxx0IP/D6ZLSnL3ZtNqiiPp5H99rxQe7kJWu0 +r+yAgD2Guua0i7Xvyf/tUwH78+H3Zxiykg5ubyEMbQ4m5H5ZQXTLgN07A3iTwpLjtPi 4d8rcw9RZKgHdi6ncJENM0c4Nfkbd5yvrdAslu+dy6NsMILoT6qC8VsL3fTJpvcHQIWc 8Ld8Fa9103hty5GeR/0h7KOFAyTowPWGvSeGJiuYeaQ5GhQtPqJYQkmkfuEn74bZuDpl s5aXzpW5uBbQ75WyLUZO5IvWdjobAylzgSIYrLgDXWx8K+e29uZnfFd9gMnMucHgmWPD hgVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=oBB1pjuGq5DBJTXzI00pR3+doKqX60PeMJxwMnGK8Zs=; b=4LkyWLleT0I8Iv4ExSC1fDx590TLDb4IxoP/JBv15bhaJWYrXdX06E8eCr86jJbcge vHzJbkqkhP0Nd6l/EYgdQ1x2JFTtH8/D/Nf1D5JkZFaPWq2OYMN5xO1sw2/nxpkAudXD JGCfnnJcWB8rUz3wGgrVAR9KiN/47ZhhgKNVy4SkCSOYGGFaCbWS3O9Ux1sePxNxKqqg njE+8KrbcU6hc2obwgP41gxyCg7GL+cfNYxTF2vMQQVECCrhUnI60iIykRpmut2+p96F Q5dBIYUgvd99I39wTD8rmrz8xZHlGLCw3u+HNJ4uJJJnZwA8fiaWe7JzW802YlMlQFpL ygHQ== X-Gm-Message-State: ACrzQf2IzT3cn7MUEyzlwzuFh5KbUpMsFUPd2caRVNZN45ATCJEWI0n+ jLy4Fhf1eiIqt60UABwsm7Q= X-Google-Smtp-Source: AMsMyM7iXa2VT9zsRWE1Wyq8gMJvooADXf4MXGjycWkwQC1yr2iKvQMrqQ42/6Po+Bbj3i/kv2eRWA== X-Received: by 2002:a5d:4572:0:b0:236:ccbe:3513 with SMTP id a18-20020a5d4572000000b00236ccbe3513mr9147191wrc.497.1667374739353; Wed, 02 Nov 2022 00:38:59 -0700 (PDT) Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id h3-20020a05600c350300b003c6deb5c1edsm1256849wmq.45.2022.11.02.00.38.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 00:38:58 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <390b18bf-7514-c8a0-9eee-76685d7ed856@HIDDEN> (Dmitry Gutov's message of "Wed, 2 Nov 2022 00:24:57 +0200") References: <87sfj8umwb.fsf@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN> <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN> <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN> <390b18bf-7514-c8a0-9eee-76685d7ed856@HIDDEN> Date: Wed, 02 Nov 2022 07:40:10 +0000 Message-ID: <875yfxu7mt.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 01.11.2022 18:23, Jo=C3=A3o T=C3=A1vora wrote: >> On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <dgutov@HIDDEN >> <mailto:dgutov@HIDDEN>> wrote: >> That's an unfair expectation: you didn't suggest an improvement >> either. >> Oh, I'm sorry, and is it fair to inquire about the subliminally >> compressed: "and eglot reinvents http-url"? Can you generously grant >> a few more sentences as to its meaning and relevance? >> Your compressed the meaning and usefulness of a feature to something > trivial (and only semi-relevant), and so did I. > I thought that would be obvious. Not only it is not, but I still have no idea what on earth you're talking about. You said "Eglot reinvents http-url", leading anyone to believe there is something in http-url that Eglot can reuse. Apparently there isn't: so you're either too clever or just wasting time.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:33:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 03:33:47 2022 Received: from localhost ([127.0.0.1]:44827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq8Fv-00017y-GI for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:33:47 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:42809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oq8Ft-00017j-KL for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:33:46 -0400 Received: by mail-wr1-f54.google.com with SMTP id cl5so11556813wrb.9 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=hkBlhjHAmwcH5wsKSvAtTfPSwxRvtlbHQBFpwqGDRRk=; b=iu2xOOC1sTx5aSZCjDrRq+GCjSZ9dJ7iJZnWivAbRgG+oxlh+706uxJEw2mvC6ZumI BNh0YaJqAxSOBdfR0gfqJyVNDPaKCt6h2CgAR7o5wkQa7SnlJR6iYCSq++TFtocy36MJ q1tjUU247Cps2WNiyMziTGq7XwV7sfZZl3NhW/mDZ0extVLr4I8I8320zm8+YQl+P8DH SBMqGT7hWehnPCxWHCiveulEB7bM1aDxWc+2qv0+e0vcUygd9VwRObXOKDO9pw/e4ReY i2C2UkKthIpXPTTHQXeJRo+qXrcCUKWy+Gqelgd4k4w9RjbR9Qzhix/kGJM58HaNYpND d2Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=hkBlhjHAmwcH5wsKSvAtTfPSwxRvtlbHQBFpwqGDRRk=; b=P8jxXJygCflGpTy8fYTtiQbk7Gjwvu7AizKANnk/3grXEly0ypR3HLSlvUg9skINwy EaHgjmHw1GdpW9FI4Zf6ummbs66mEasSsqvUF2RXO3LSap4hfXZkRnv1gN2P0L7Y54t9 e6a1oaF8zIsb0+L5hfskP/m89U33sfWwwq1xv2GHzol6mIKKndeGq9lxZ2f8ybtjFnQ8 BHWhArfI9cLJ8Ce39ufXUJqS9NfvE1OxhoHcoDwKRrHR3R/Vfn84G8/KPGKhUXz7HfiY gbwPLqFeJtQI51xYHm0oJkpq2DHMp/TuuuWefS2o7NFrrtfI4IWHLwxx2usXZztI1j0q IL/Q== X-Gm-Message-State: ACrzQf0jBoN9r/vljvzgVPm8VVYog1dbbH4RxlxcPP3/8hnHHboYLas2 0jaRF7OeXYClm1xicxPw66k= X-Google-Smtp-Source: AMsMyM4ei06dbaNaak3aHBKTTrk4fTWansaRpe3L8xFCz6mrvBJTqfT3t49B5wn6IxPiWxLIJUYAaw== X-Received: by 2002:adf:ab1d:0:b0:236:6301:c77 with SMTP id q29-20020adfab1d000000b0023663010c77mr13765297wrc.119.1667374419806; Wed, 02 Nov 2022 00:33:39 -0700 (PDT) Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id r17-20020a05600c459100b003c7087f6c9asm1304919wmo.32.2022.11.02.00.33.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 00:33:39 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> (Dmitry Gutov's message of "Wed, 2 Nov 2022 00:23:11 +0200") References: <87sfj8umwb.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> Date: Wed, 02 Nov 2022 07:34:51 +0000 Message-ID: <87a659u7vo.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: >> I've explained to Philip objective reasons why I think evaluated >> mini-languages are almost always inferior to a decent Lisp such as Elisp. >> 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. 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". 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
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:30:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 03:30:08 2022 Received: from localhost ([127.0.0.1]:44821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oq8CN-00012W-OS for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:30:08 -0400 Received: from mout02.posteo.de ([185.67.36.66]:35065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oq8CM-00010W-Kg for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:30:07 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 40ED8240101 for <58839 <at> debbugs.gnu.org>; Wed, 2 Nov 2022 08:29:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667374200; bh=jy9zFtFpB2mdtCFIsUzVAtH85CIH4/+iMLHUrPnmG6c=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=XJ5iAdUTJdkzFt8NjNbPXyD6PT8pct25g6YuuZq+efnCFgL7YhXXiE53B32PH579L uYQ7bBGGo3vjv8EMY7N4w8GoFPK4jLnzVUjO+8Q8Ko++ZWSawTq5WGN2l9cW0CZvSH ewJN1eXU7lk8gVrxfXN4BAOlzmwD7KYVZf3USEG81zyitNHBEHuoRaUasXNAJquBdj mFW7M7jogIgy+0IWVieyNQ7nEWat1/e/mYXq35dWjCsdQcaREndppClkmFv++qLNk2 5n10Z+X48AsVb8aoLrQ1C2n8chd6bcU/r34FsKWsRWjY9Dhx/B/q502T4dQbI6pDJ9 M1R/OuItgLeiA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2JSQ4LqMz9rxH; Wed, 2 Nov 2022 08:29:58 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87edulu8ly.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Wed, 02 Nov 2022 07:19:05 +0000") References: <87sfj8umwb.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> <87edumg4fd.fsf@HIDDEN> <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN> <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Wed, 02 Nov 2022 07:29:58 +0000 Message-ID: <87wn8dbyq1.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Philip Kaludercic <philipk@HIDDEN> writes: > >>> Yes, do that, but use byte-compile instead, not eval. >> I have tried both, and it doesn't appear to be a particular advantage >> one way or another. That being said, this approach is *a lot* faster, >> to the point that I first assumed it was broken: > > Yes, this approach is always going to be much faster than the "naive" > approach. Now I've taken your code as a starting point, simplified it, > and I get a reasonable/typical 3.5x speedup when I use a > byte-compilation strategy, so one of us isn't measuring > > ```elisp > (defun translate-buffer-condition-1 (condition) > (pcase-exhaustive condition > ((or 't 'nil) > condition) > ((pred stringp) > `(string-match-p ,condition (buffer-name buffer))) > ((pred functionp) > `(,condition buffer)) This would break the current behaviour, because `buffer-match-p' requires the function be called with an additional argument if possible. This is fundamental for `display-buffer-alist' to work. > (`(major-mode . ,mode) > `(eq (buffer-local-value 'major-mode buffer) > ',mode)) > (`(derived-mode . ,mode) > `(provided-mode-derived-p > (buffer-local-value 'major-mode buffer) > ',mode)) > (`(not . ,cond) > `(not ,(translate-buffer-condition-1 cond))) > (`(or . ,conds) > `(or ,@(mapcar #'translate-buffer-condition-1 conds))) > (`(and . ,conds) > `(and ,@(mapcar #'translate-buffer-condition-1 conds))))) > > (defun translate-buffer-condition (condition) > `(lambda (buffer) ,(translate-buffer-condition-1 condition))) > > (defvar sample-condition > '(and (or buffer-file-name > (derived-mode . compilation-mode) > (derived-mode . dired-mode) > (derived-mode . diff-mode) > (derived-mode . comint-mode) > (derived-mode . eshell-mode) > (derived-mode . change-log-mode)) > "\\*.+\\*" > (not . "\\` "))) > > (defvar form (translate-buffer-condition sample-condition)) > (defvar compiled (byte-compile form)) > > (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.39740= 4883 3 0.18942550900000032) > (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.11365183= 6 0 0.0) > ``` > > I couldn't understand the need for a hash table or special symbol vars > or what that "arg" was, so I took it out, but it shouldn't make a > difference. The hash table makes a significant different, try evaluating (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffer))= ) ;; (0.113651836 0 0.0) I have created a new bug report for this issue bug#58950, so that this one can return to the topic of project.el. The fresh symbols are used to keep the code clean and avoid possible naming conflicts.=20
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:18:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 02 03:18:04 2022
Received: from localhost ([127.0.0.1]:44795 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oq80i-0000hP-BO
for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:18:04 -0400
Received: from mail-wm1-f49.google.com ([209.85.128.49]:44584)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1oq80f-0000gu-AX
for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:18:02 -0400
Received: by mail-wm1-f49.google.com with SMTP id
bg9-20020a05600c3c8900b003bf249616b0so650696wmb.3
for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:message-id:date:user-agent:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=hU+5R90vBsr/0Crp/BwTf7LXS34HJ3Ok1fW9zRfb5BY=;
b=JQXquJfCc0e/8qLYbCEdiqbiaCDwmjastWMJF0W6djQFXbNl+7sUacvo6x/VJ6IQTe
Xq7+2jgGj+wIJxC9GgpTuh/BNNKz3Fd/wVNDaGFnBq2fO4usL58DZ7uVkf0tVHpTNkOe
NS4vgnl1vXUmJ0h3ggi79TZVMF1CXr7vG5syB/HhBGejdqg16DRqsyoJg5fpKLom30CC
QQDL1jy6Tsnp3T4//v1cEc+4KmE3k8mVieM5rUCsgHGLghJPQkj5H8z/lPhDBlcD7KVd
lt4jA2OC/xptcZ0q+zRwA6LvGsMkjvlOpmrklq++qvxaAuyCEhQTdComz+pPb5ohZz28
VPSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=mime-version:message-id:date:user-agent:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=hU+5R90vBsr/0Crp/BwTf7LXS34HJ3Ok1fW9zRfb5BY=;
b=NobjfKNrw1ZD3ExQrYomLYO3WxGLOJZD8F4myoTrR92DwqhVjrGfwB3dP0X8QQvb5U
m6mGYqmrCHDdvZojdqywuu4NhU0wG/i321eBIFcILSYHNVfbFJMyJ1Iz29tZ8Nr+qWC0
PyAiIaluZeMG7gPfu3a7RbHqCXJemVS/lmKwJA7aK9caGNMo/sYR3m4uE50BrViptBz8
ve7edNT8vebM/kJU0A1TF35+lyq4W+egog05tSjpChgR0YaqdgEL/CpcXeqJDD8B4FVn
5OlyNnLZfuWqrpz7fJqzBapTpZ1jJmNkGCR5nn1zqq8eEQ9B6ckftuHI0w5DTu7W2wkk
XY1w==
X-Gm-Message-State: ACrzQf0oCwRrQpoenAsTb/1BB+RecGigqolDQxWK5/gKI2obUAu9yFPt
JwU0jhErwGRsS5J241AwSgAR0G4wnZo=
X-Google-Smtp-Source: AMsMyM6aowOpSNj9yAGA0DjwgCE6jkHHqA2ZuNOAe3ET+RjtsJmYfLJTRyFfeY/uUYLK23XlG35M6w==
X-Received: by 2002:a05:600c:1614:b0:3cf:816e:4a69 with SMTP id
m20-20020a05600c161400b003cf816e4a69mr3941993wmn.33.1667373474964;
Wed, 02 Nov 2022 00:17:54 -0700 (PDT)
Received: from krug ([87.196.73.80]) by smtp.gmail.com with ESMTPSA id
v7-20020a05600c444700b003c70191f267sm1051916wmn.39.2022.11.02.00.17.53
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 02 Nov 2022 00:17:54 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <874jvig2rp.fsf@HIDDEN> (Philip Kaludercic's message of "Tue,
01 Nov 2022 14:36:42 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
<871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
<87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
<837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
<87h6zihq3q.fsf@HIDDEN>
<CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
<877d0ehlnb.fsf@HIDDEN>
<CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
<87edumg4fd.fsf@HIDDEN>
<CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
<874jvig2rp.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Date: Wed, 02 Nov 2022 07:19:05 +0000
Message-ID: <87edulu8ly.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Philip Kaludercic <philipk@HIDDEN> writes:
>> Yes, do that, but use byte-compile instead, not eval.
> I have tried both, and it doesn't appear to be a particular advantage
> one way or another. That being said, this approach is *a lot* faster,
> to the point that I first assumed it was broken:
Yes, this approach is always going to be much faster than the "naive"
approach. Now I've taken your code as a starting point, simplified it,
and I get a reasonable/typical 3.5x speedup when I use a
byte-compilation strategy, so one of us isn't measuring
```elisp
(defun translate-buffer-condition-1 (condition)
(pcase-exhaustive condition
((or 't 'nil)
condition)
((pred stringp)
`(string-match-p ,condition (buffer-name buffer)))
((pred functionp)
`(,condition buffer))
(`(major-mode . ,mode)
`(eq (buffer-local-value 'major-mode buffer)
',mode))
(`(derived-mode . ,mode)
`(provided-mode-derived-p
(buffer-local-value 'major-mode buffer)
',mode))
(`(not . ,cond)
`(not ,(translate-buffer-condition-1 cond)))
(`(or . ,conds)
`(or ,@(mapcar #'translate-buffer-condition-1 conds)))
(`(and . ,conds)
`(and ,@(mapcar #'translate-buffer-condition-1 conds)))))
(defun translate-buffer-condition (condition)
`(lambda (buffer) ,(translate-buffer-condition-1 condition)))
(defvar sample-condition
'(and (or buffer-file-name
(derived-mode . compilation-mode)
(derived-mode . dired-mode)
(derived-mode . diff-mode)
(derived-mode . comint-mode)
(derived-mode . eshell-mode)
(derived-mode . change-log-mode))
"\\*.+\\*"
(not . "\\` ")))
(defvar form (translate-buffer-condition sample-condition))
(defvar compiled (byte-compile form))
(benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.397404883 3 0.18942550900000032)
(benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.113651836 0 0.0)
```
I couldn't understand the need for a hash table or special symbol vars
or what that "arg" was, so I took it out, but it shouldn't make a
difference.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 22:40:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 18:40:43 2022 Received: from localhost ([127.0.0.1]:44411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opzw2-00063L-KK for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:40:43 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:39807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opzvz-000637-Ju for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:40:40 -0400 Received: by mail-wm1-f51.google.com with SMTP id i5-20020a1c3b05000000b003cf47dcd316so209115wma.4 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 15:40: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=hLYuRGGCo12V3KLBoBAJ+2BiaYkKMr30E+AzaZd+UoI=; b=ligsoTQh6lKjDBzc/gmB2iQJCSQ4BSnd55UyhbY8xB9+EXpFxXY5g1gvge/dHEyq5/ sWFk20imJGkfly3L28JX/LmsNwRnjHz6XPr3M18GJeRDIdUvaUKnvDymojHFmCENHgWP AbV1XqfW8h4GlOBMxeAzIpTgP4OWYNjmT3SeqP9fhle6oFlKwSSoY3YmuWcFjqc423QO cGphsRxYl8i3KtPvsV9WQNZwpfsdW+06Z54zITjeOU7w+vgrGdtu0BY1Ep9mfhRKmm0d iR771SywximHsiNGrJbiMxotA5vOeDQTRqoYqgTo32DZ44SOK4Uy8INM6zroiUaD/uq2 w8nw== 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=hLYuRGGCo12V3KLBoBAJ+2BiaYkKMr30E+AzaZd+UoI=; b=y+hXWi+522Ft2etyl6U9cxS/Lpky6tEL7PpD2fv5xRwk5r6YKppqeEkrBvUmQMpmg0 BNsIHeeiUjaZM5O9Jwo+7EpHsmNmNOAk9hxkZk41foNP1uB2mSTOPt7gUCWqKnrxpurT 86RBIhxtkw1KU/b7/Mp0MI6Jp1TFCiNQVAXCIj6EAoR/71LnzPcCCByyudLVmauuqJd4 7KBep9VXbKlQ3WDhZa49ESxWieHC3uUPJKWVoldHNdD99yGFWpG1GLVqN9Vs388WHPbr nytXs/J1AwSm8VoNlGTIARtw4CdzM2pUtHqxvZv8YapQdihUq2bmN4bExCa/wDUwUurL Md6Q== X-Gm-Message-State: ACrzQf1MT0DmutqSMlCBlf4BgE+mqssiTELHFV/t69jjt37GDglQF6nT gkU4u7aM6WR2Fwp0QF8hTHk= X-Google-Smtp-Source: AMsMyM4qbjDPCE6wvHhAV/RrFIOCJBRY2BUfJhDsTX17XDXssUJZytivJboJj/x7l2AG8/AdHQeedg== X-Received: by 2002:a05:600c:3b88:b0:3c6:cef8:8465 with SMTP id n8-20020a05600c3b8800b003c6cef88465mr23287139wms.64.1667342433556; Tue, 01 Nov 2022 15:40:33 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id p125-20020a1c2983000000b003c21ba7d7d6sm22647wmp.44.2022.11.01.15.40.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 15:40:33 -0700 (PDT) Message-ID: <0ff05982-860b-7338-8bb6-50ac09cc376a@HIDDEN> Date: Wed, 2 Nov 2022 00:40:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> <87bkpqecpv.fsf@HIDDEN> <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN> <87wn8ecu5s.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87wn8ecu5s.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 22:10, Philip Kaludercic wrote: > Dmitry Gutov <dgutov@HIDDEN> writes: > >> On 01.11.2022 20:44, Philip Kaludercic wrote: >> >>>> Sure, but only after we're ready to drop project.el support for Emacs >>>> older than 29. >>> The functionality can be provided using Compat[0], as is already >>> done for a >>> few core package that are distributed on GNU ELPA (ERC, python-mode). >>> [0] https://elpa.gnu.org/packages/compat.html >> >> I suppose if the performance improvement is shown to be significant, >> we could. I'm a little hesitant to add a new dependency: I haven't >> been following this package, not sure how stable it is. > > I am the maintainer, so I am biased, but stability is a high priority, > which is why the library is extensively tested, where-ever possible: > > https://git.sr.ht/~pkal/compat/tree/master/item/compat-tests.el > > Fun fact, I came up with the idea for this library when working on > project-kill-buffer over two years ago, as a means of extracting the > language out of project.el, as has been done with buffer-match-p. Oh ok. I suppose I don't mind, then. It would be nice to have some benchmark, however, at what number of buffers the optimization brings some perceptible difference (like, the delay is reduced by 50ms at least). >>>>> +(defcustom project-buffer-conditions >>>> >>>> Why not keep considering unknown buffers as part of project by default? >>> What are "unknown buffers"? >> >> Take whatever special buffer belonging to jsonrpc that was the cause >> of this bug report. It can still be useful to be able switch to it >> using project-switch-to-buffer (if, say, one was looking for the >> specific buffer to try to debug a problem with some Eglot feature in >> their project). We don't want to kill it with the rest of the buffers, >> however. Apparently. > > Ah, right. I have to admit that I rarely use project-switch-to-buffer, > so I forgot about that. In that case, project-kill-buffer-conditions > cannot be deprecated, as these are just a subset of the project buffers. There can be other uses for 'project-buffers' as well, like the reimplementation of projectile-ibuffer in another bug report. >>>> We'll just stop killing them on cleanup. >>>> >>>> Otherwise, we'll really need an extensible mechanism for major modes >>>> all around the ecosystem to tag themselves as project-visible. >>> Wouldn't a simple buffer local variable suffice? >> >> I guess it will. Only with a more meaningful name than 'project-owned' >> and some proper documentation. > > Right. Does it have to have a "project-" prefix, or would > "belongs-to-project" (hypothetically) be fine too? Let's keep to the module-prefixing strategy. I think it makes sense, and the rest of the symbols in project.el are named that way. >>>>> + '(and (or buffer-file-name >>>>> + (derived-mode . compilation-mode) >>>>> + (derived-mode . dired-mode) >>>>> + (derived-mode . diff-mode) >>>>> + (derived-mode . comint-mode) >>>>> + (derived-mode . eshell-mode) >>>>> + (derived-mode . change-log-mode)) >>>>> + project-includes-buffer-p) >>>>> + "A buffer predicate for matching what buffers belong to a project." >>>>> + :type 'buffer-predicate) >>>> >>>> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others. >>> This is my point, I think João is right that this ought to be an >>> enumeration of major modes that are related to projects. As this is a >>> user option, users can add or remove whatever modes they disagree on and >>> that behaviour would ideally be propagated to all projects. >> >> Being to customize it is a good thing. >> >> But either we provide a reasonably complete list which we regularly >> update, or we say its completeness is up to the user. > > I would want to argue that the complete list is preferable. Then we'll have to keep updating it from time to time. >> And in the latter case, as soon as the user customizes the var, they >> stop getting any updates we might make to it later (to the default >> value). >> >> And if we take the strict "whitelist" approach, I'm pretty sure the >> list will require updating in the future, it will never be complete. > > Which is fair, but which can also be combined with (unfinished)
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 22:25:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 18:25:06 2022 Received: from localhost ([127.0.0.1]:44386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opzgw-0005eh-6J for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:25:06 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:41860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opzgv-0005e8-25 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:25:05 -0400 Received: by mail-wr1-f45.google.com with SMTP id w14so22026101wru.8 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 15:25:05 -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=Gngs3FhLxI7mtplV+oX/20a8n2l7ocT97UN73yjEG/g=; b=YkUjXbWwg1GYm3UIFt3z3upwXmly8kWwzb7XfvE/Cv1Il+Lk0owTUTqeoPYwPbs+A6 nAEx0xQ3GTf8oxbtxyIKThTI2BoG3bbUxRqujrdLj0tjXnuxUsG8z1SReshwlUEHvkbv uOnjRv2BwYNVmGTO7HtmmXu/QIv5A5yC3rpPjP/iphPk6wsljWfrJA6pu7dvNRXU2OUW f3NuDNUxGJA7Gdf6kHEI/kcZ01pLYmhkDOx3dzbVvRIWj0vUSK0vD8TgjWaFZC9TW+az DMbms5EdQGLzIJrUrvsDkLO4AahZ5msvE7Es4QKEFReTZUa6wt8+uI4Beq8oE1cWTg+i YIdg== 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=Gngs3FhLxI7mtplV+oX/20a8n2l7ocT97UN73yjEG/g=; b=OKwlt9oNTRx1j/llur9SHN7u9uH0YSLBF07JbBZ9cnlpyphisWR6UMJ1hHk2WFD1qm 5XvOiY88eWf3/CKGG9GMcQqe7BJ24PghGhanYG2PBK0bnfeBq0DryhZb1eDv6487KEcY c/kigvV6QNdpOm/yjyZKaUPp3mLfX4oLMYlk015y0bzw8mClvXqhttu2gY38BuynW6yd YclfHtMTWqEMFAJF4lAadS1bRvsJ/0jHc4upgNTj3aJzVdHRu4t9pxRE66Y9z60hA37V qgRGIvwYu00f+vY1oE91OzNwplvKCwlJ9ieq4EzcFywosnBLFotlPocdwfQpuRPn+EKD 7ohQ== X-Gm-Message-State: ACrzQf05mP8kWnkhTbfQOl/L+LArmXm1+gVwuE0lQwdM+FBqcl6TNEzv eaenkuK/2myiOw7T/fuOl+I= X-Google-Smtp-Source: AMsMyM77wsWzgAFP7tuZhGPZhsZZS4VMGCUnYU/f90wwlsWIzp1/aTUdZJiVMGv4Ti3CYEkEZZmajQ== X-Received: by 2002:adf:cd09:0:b0:236:659a:6902 with SMTP id w9-20020adfcd09000000b00236659a6902mr13420592wrm.574.1667341499338; Tue, 01 Nov 2022 15:24:59 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id e12-20020adfe38c000000b0023655e51c14sm11087214wrm.32.2022.11.01.15.24.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 15:24:59 -0700 (PDT) Message-ID: <390b18bf-7514-c8a0-9eee-76685d7ed856@HIDDEN> Date: Wed, 2 Nov 2022 00:24:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN> <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN> <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 18:23, João Távora wrote: > On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <dgutov@HIDDEN > <mailto:dgutov@HIDDEN>> wrote: > > That's an unfair expectation: you didn't suggest an improvement either. > > > Oh, I'm sorry, and is it fair to inquire about the subliminally > compressed: "and eglot reinvents http-url"? Can you generously grant a > few more sentences as to its meaning and relevance? Your compressed the meaning and usefulness of a feature to something trivial (and only semi-relevant), and so did I. I thought that would be obvious.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 22:23:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 18:23:21 2022 Received: from localhost ([127.0.0.1]:44381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opzfE-0005bn-MQ for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:23:20 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:46077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opzfC-0005ba-OQ for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:23:19 -0400 Received: by mail-wm1-f52.google.com with SMTP id l16-20020a05600c4f1000b003c6c0d2a445so189206wmq.4 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 15:23:18 -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=tJKeiNE9fX7ZtS3ybHLkEuWa3MdlhUOGaP4Qxe0an/o=; b=N73NhAxMAfvcxTs4jqguWpPlbBS5Q5N0raNzuUt1Vjsv+zMdcEzo4DHm3Plgv/Ua06 /bEElq+g78zV4GM3Wffwg+pYFhYj7zNJgkk7P/ep206x5eTo++sQ8Ca2JHCmyGNmHlzu ovg5KO3V19x61xcCL+TE0P4hBrROMN8cDW8jgxEbIPSQ+8JxhBLZzT6mpt+7/hCOqetA CpE9yHtE7Vfn5CME22ks7MixMTfYY3vB0V3u8h9cFZxZ4MJeT13YRa9R1/m90F4DqjKl BuFDdWUKfFDqRBmZ2XKRv6wN48isZeivklCtr0bhTbsJRr+dV7P02aqhteVtT2mCLRoS Ka3Q== 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=tJKeiNE9fX7ZtS3ybHLkEuWa3MdlhUOGaP4Qxe0an/o=; b=S3HdgKe0QKlr5QPPrloY8Dzh9JLHaz20q08OaEneKJwky1hZgTq0njrr23emXQTV9J Ng3vzg58biwlBkdxGkdKNrqbwpwuyRgBAIrrAdJOtLwfVCt8YFgnye1Nyzc8/4Xylmd8 dVEz26i6M2H/rMVsmHCLEjevbPYnyxs8C5lwfVO5lgKhWYAtdznChgj8Z3QZ8BNsfLk0 P/5f1yDLojn1KItOVgMdfv7njLnxrgGB5SWlNqaE8Nc0G9bYlKWsCT0xzXnBkR58dC0W hpvnBx6QV8aRjsnFe+bgfR0nH0k9ZebAPhKiQIftiqHMZ/aTLaA846WC6Eax/W8NiEMi /kmg== X-Gm-Message-State: ACrzQf2qlbHu6vG156BDi6/shfoOL7cO2AW/aItJwbUcx8uvm6U7u6ve Az5W2Ad1EzpL4DNSQ83hcw4= X-Google-Smtp-Source: AMsMyM4zHb7Nafy2wd1hAHEECVEMfKkUi4fwzfVlDt+z7d+SkCaXFeulUKpYgg+o0zorQrd94YZy5Q== X-Received: by 2002:a7b:c3c4:0:b0:3c4:785a:36d7 with SMTP id t4-20020a7bc3c4000000b003c4785a36d7mr23830593wmj.138.1667341392965; Tue, 01 Nov 2022 15:23:12 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u13-20020a056000038d00b00236c1f2cecesm10579411wrf.81.2022.11.01.15.23.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 15:23:12 -0700 (PDT) Message-ID: <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> Date: Wed, 2 Nov 2022 00:23:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 13:36, João Távora wrote: > > 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. > > You are attributing ill-intent to me from a moral high-ground you can't > really > claim. I had no idea as to the authorship, so I can't have been > engaging in those > perfidious tactics. But do I apologize for the word "abomination". If > it helps > I'll show you round to plenty such things written by myself in the past. Not at all, trying to get people to agree to your own (obviously correct and beneficial) POV is not ill intent. The means are not great, though. > I've explained to Philip objective reasons why I think evaluated > mini-languages are almost always inferior to a decent Lisp such as Elisp. > You could perfectly reasonably deprecate these two variables. Not where this discussion is going, is it? > > 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".
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 20:11:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 16:11:13 2022 Received: from localhost ([127.0.0.1]:44287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opxbM-00006P-G6 for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 16:11:13 -0400 Received: from mout02.posteo.de ([185.67.36.66]:39145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1opxbK-00006A-AE for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 16:11:11 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 29A99240106 for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 21:11:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667333464; bh=TJqedmjYJtsV+82B5OQs0rL8oWfXRj6ww3vnHrPpjIY=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=qL0k1x5eaw62ZCYuOsy/42e/2yNBeuK2NlQZRdcoG/IvxyyHpOHFr9RrWvRNjBfw4 FQbmPq6uammj6po7Tgg/ocVwgLUpimLMB7efuHmLCyPbZn/wDhbXFz40/vbYvFXe5i HcdbdFjOrx36LV6jfaFx1POs9JbjtDH1wbpzt8Kk12LIZHlVzIL4B1Tu8XxRq8CchR 1EJEojtct40zC6sRKibsP85zF7Cl9lrXAhPbHFmv42WGuGxYT96r328KHFtGuLt/DF fUH8cBmGgLo9MblGAzBJDVV1Tk74yhnMoUr5T0EZKO88R8ZaE/K55vMOhfdnjQWG3u JxRU36dP794kw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N21P22vHgz9rxV; Tue, 1 Nov 2022 21:11:02 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN> (Dmitry Gutov's message of "Tue, 1 Nov 2022 21:50:17 +0200") References: <87sfj8umwb.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> <87bkpqecpv.fsf@HIDDEN> <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Tue, 01 Nov 2022 20:10:55 +0000 Message-ID: <87wn8ecu5s.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 01.11.2022 20:44, Philip Kaludercic wrote: > >>> Sure, but only after we're ready to drop project.el support for Emacs >>> older than 29. >> The functionality can be provided using Compat[0], as is already >> done for a >> few core package that are distributed on GNU ELPA (ERC, python-mode). >> [0] https://elpa.gnu.org/packages/compat.html > > I suppose if the performance improvement is shown to be significant, > we could. I'm a little hesitant to add a new dependency: I haven't > been following this package, not sure how stable it is. I am the maintainer, so I am biased, but stability is a high priority, which is why the library is extensively tested, where-ever possible: https://git.sr.ht/~pkal/compat/tree/master/item/compat-tests.el Fun fact, I came up with the idea for this library when working on project-kill-buffer over two years ago, as a means of extracting the language out of project.el, as has been done with buffer-match-p. >>>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >>>> index ac278edd40..b55c245368 100644 >>>> --- a/lisp/progmodes/project.el >>>> +++ b/lisp/progmodes/project.el >>>> @@ -352,15 +352,28 @@ project--remote-file-names >>>> (concat remote-id file)) >>>> local-files)))) >>>> +(defun project-includes-buffer-p (buffer dir) >>>> + "Return non-nil if the `default-directory' of BUFFER is below DIR." >>>> + (file-in-directory-p >>>> + (buffer-local-value 'default-directory buffer) >>>> + dir)) >>> >>> Not an optimal name, given that we have made project-buffers a generic >>> function, so that a custom project backend can define their own >>> buffer-listing strategy. And this one implies that matching by >>> default-directory is universal. >> Right, as I said this is just a sketch. >> But as the diff showed, I think any more specific implementation >> ought >> to extend the generic implementation, by using `cl-call-next-method' >> instead of `buffer-list'. > > Or apply the same filters some other way, I guess. But yes, the > cl-call-next-method call makes sense in your patch. > >>>> +(defcustom project-buffer-conditions >>> >>> Why not keep considering unknown buffers as part of project by default? >> What are "unknown buffers"? > > Take whatever special buffer belonging to jsonrpc that was the cause > of this bug report. It can still be useful to be able switch to it > using project-switch-to-buffer (if, say, one was looking for the > specific buffer to try to debug a problem with some Eglot feature in > their project). We don't want to kill it with the rest of the buffers, > however. Apparently. Ah, right. I have to admit that I rarely use project-switch-to-buffer, so I forgot about that. In that case, project-kill-buffer-conditions cannot be deprecated, as these are just a subset of the project buffers. >>> We'll just stop killing them on cleanup. >>> >>> Otherwise, we'll really need an extensible mechanism for major modes >>> all around the ecosystem to tag themselves as project-visible. >> Wouldn't a simple buffer local variable suffice? > > I guess it will. Only with a more meaningful name than 'project-owned' > and some proper documentation. Right. Does it have to have a "project-" prefix, or would "belongs-to-project" (hypothetically) be fine too? >>>> + '(and (or buffer-file-name >>>> + (derived-mode . compilation-mode) >>>> + (derived-mode . dired-mode) >>>> + (derived-mode . diff-mode) >>>> + (derived-mode . comint-mode) >>>> + (derived-mode . eshell-mode) >>>> + (derived-mode . change-log-mode)) >>>> + project-includes-buffer-p) >>>> + "A buffer predicate for matching what buffers belong to a project." >>>> + :type 'buffer-predicate) >>> >>> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others. >> This is my point, I think Jo=C3=A3o is right that this ought to be an >> enumeration of major modes that are related to projects. As this is a >> user option, users can add or remove whatever modes they disagree on and >> that behaviour would ideally be propagated to all projects. > > Being to customize it is a good thing. > > But either we provide a reasonably complete list which we regularly > update, or we say its completeness is up to the user. I would want to argue that the complete list is preferable. > And in the latter case, as soon as the user customizes the var, they > stop getting any updates we might make to it later (to the default > value). > > And if we take the strict "whitelist" approach, I'm pretty sure the > list will require updating in the future, it will never be complete. Which is fair, but which can also be combined with=20
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 19:50:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 15:50:31 2022 Received: from localhost ([127.0.0.1]:44273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opxHL-00083m-F6 for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 15:50:31 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:34437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opxHF-00083O-TS for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 15:50:30 -0400 Received: by mail-wr1-f48.google.com with SMTP id k8so21616106wrh.1 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 12:50:25 -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=WZNy+6SKezqjjP3kFxt7Eg0TJCKi7bAot/hk0eNUJgw=; b=LMHiI4Kvxlf/UFWKpVkDqJ9/V5PzNnSAVatwumMzxVCSVpQsib8TbdM3yFI0MmhRAl WC6p2wOSrmdDImb5L2IZZ6G3AHHKc3zzFuNNmKu87d7tZFXNOfDji5w1QeuEJ3vuLi1+ riAmhfunyUykhPRPLKxkyDDivDkyLgHQzKTFWlV3s6DeZJLcivti1g7gPZ+E2ODNJXrX EaN4MmvbfA++wbyVz4AFWopy+0QQQm6lJRk3I9XMyam9BhQB6cNNO4F18pVha31Nt74W oCz9Ytih4aOzIQGvO8dnhPV+fHwu5eZoExjPCBp4lHzxWSybGTQlB0ZnaYVip2IWXKrJ cT+A== 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=WZNy+6SKezqjjP3kFxt7Eg0TJCKi7bAot/hk0eNUJgw=; b=1kvshk5UjCCRIi4Kuf+WBM5VwNgNkSHaKY33rAqse93Q5xQG2+4WWbMagxUy7/Nw5I igf8pdY+27QMAuIG2xRtWXvox0aFO+xxP3Y7VBWVZFTlPZlLp6wVaK+8SSsghrqqhLQ+ gjdr0XPsYhEQTpeHtJIIKCY0xzymo08fLaujoWO8rIX/MYkwsRRcNBcg0kw2fb6xQR54 RcOq4LK5LMcbiidN9qD0vD951L1OIcLBZg0LjZloWyJpj/v3K+IDJULompgmj1AkQRby O1YpmP6OjgRBQCDvQZ+PjP/vO/IezKiFbkL93a5lnvAjmPP1NbLKIXzR8Xtw35hkO9Mn E1Gw== X-Gm-Message-State: ACrzQf1VRDanatKfGvENMjGXIqBbfhpwso3Mf6uziuGJoU6sqzdiatOz tvLxvwjimHQmSd0/UsjfPSw= X-Google-Smtp-Source: AMsMyM7jCp0//Qenh2x8D8ykbdsSqMoQu6/Oazg5xC4Q1SJFcG2vdBM7e+riZs2Faz1oKr4jJIzAtQ== X-Received: by 2002:adf:e785:0:b0:236:5998:67a0 with SMTP id n5-20020adfe785000000b00236599867a0mr12895099wrm.414.1667332219791; Tue, 01 Nov 2022 12:50:19 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h9-20020a05600c414900b003b49ab8ff53sm11361322wmm.8.2022.11.01.12.50.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 12:50:19 -0700 (PDT) Message-ID: <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN> Date: Tue, 1 Nov 2022 21:50:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> <87bkpqecpv.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87bkpqecpv.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 20:44, Philip Kaludercic wrote: >> Sure, but only after we're ready to drop project.el support for Emacs >> older than 29. > > The functionality can be provided using Compat[0], as is already done for a > few core package that are distributed on GNU ELPA (ERC, python-mode). > > [0] https://elpa.gnu.org/packages/compat.html I suppose if the performance improvement is shown to be significant, we could. I'm a little hesitant to add a new dependency: I haven't been following this package, not sure how stable it is. >>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >>> index ac278edd40..b55c245368 100644 >>> --- a/lisp/progmodes/project.el >>> +++ b/lisp/progmodes/project.el >>> @@ -352,15 +352,28 @@ project--remote-file-names >>> (concat remote-id file)) >>> local-files)))) >>> +(defun project-includes-buffer-p (buffer dir) >>> + "Return non-nil if the `default-directory' of BUFFER is below DIR." >>> + (file-in-directory-p >>> + (buffer-local-value 'default-directory buffer) >>> + dir)) >> >> Not an optimal name, given that we have made project-buffers a generic >> function, so that a custom project backend can define their own >> buffer-listing strategy. And this one implies that matching by >> default-directory is universal. > > Right, as I said this is just a sketch. > > But as the diff showed, I think any more specific implementation ought > to extend the generic implementation, by using `cl-call-next-method' > instead of `buffer-list'. Or apply the same filters some other way, I guess. But yes, the cl-call-next-method call makes sense in your patch. >>> +(defcustom project-buffer-conditions >> >> Why not keep considering unknown buffers as part of project by default? > > What are "unknown buffers"? Take whatever special buffer belonging to jsonrpc that was the cause of this bug report. It can still be useful to be able switch to it using project-switch-to-buffer (if, say, one was looking for the specific buffer to try to debug a problem with some Eglot feature in their project). We don't want to kill it with the rest of the buffers, however. Apparently. >> We'll just stop killing them on cleanup. >> >> Otherwise, we'll really need an extensible mechanism for major modes >> all around the ecosystem to tag themselves as project-visible. > > Wouldn't a simple buffer local variable suffice? I guess it will. Only with a more meaningful name than 'project-owned' and some proper documentation. >>> + '(and (or buffer-file-name >>> + (derived-mode . compilation-mode) >>> + (derived-mode . dired-mode) >>> + (derived-mode . diff-mode) >>> + (derived-mode . comint-mode) >>> + (derived-mode . eshell-mode) >>> + (derived-mode . change-log-mode)) >>> + project-includes-buffer-p) >>> + "A buffer predicate for matching what buffers belong to a project." >>> + :type 'buffer-predicate) >> >> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others. > > This is my point, I think João is right that this ought to be an > enumeration of major modes that are related to projects. As this is a > user option, users can add or remove whatever modes they disagree on and > that behaviour would ideally be propagated to all projects. Being to customize it is a good thing. But either we provide a reasonably complete list which we regularly update, or we say its completeness is up to the user. And in the latter case, as soon as the user customizes the var, they stop getting any updates we might make to it later (to the default value). And if we take the strict "whitelist" approach, I'm pretty sure the list will require updating in the future, it will never be complete.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 18:44:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 14:44:57 2022 Received: from localhost ([127.0.0.1]:44240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opwFs-0006P7-Ud for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 14:44:57 -0400 Received: from mout01.posteo.de ([185.67.36.65]:42093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1opwFq-0006Ot-OD for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 14:44:55 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id CD692240026 for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 19:44:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667328288; bh=mEhE/62hKYoX/8kmrd60brjjblsL3yWmXLZnu4rCmac=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=PZBVW1udyIv9n3gnyuyGxU6xi2Eqnt93MgTrzPpSrO0ObpbPt3MMoAxanSAPIjDAF hU8rr9Y+Fquyu6VRHxOk7o4/cKXWrJIg1VL+WrbF5+6yGtHSMwA1hdOVwwG+r+n257 8xZJfHryfmlznmurLE1qMDQnyJCUlu6nOJIbUxxvyB9ePVhYhpptirLrpv8vPLYufl T2jAxuy3DDj1MTTyx89dGZePRbnxcDMfp3y1uiZxb7UZgWB0GdUjf65cM12YKG5w// OvhemhpiF3NKoH22+Lld/bOgGp3ajJszBaLJSlHL0kYb7AE5smwFp87XWd5shmyxkw C3baw0Tuv1sUQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1zTT2dnxz6tmf; Tue, 1 Nov 2022 19:44:45 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> (Dmitry Gutov's message of "Tue, 1 Nov 2022 17:26:26 +0200") References: <87sfj8umwb.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Tue, 01 Nov 2022 18:44:44 +0000 Message-ID: <87bkpqecpv.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > On 01.11.2022 13:27, Philip Kaludercic wrote: > >> I am biased, but I believe that the language could even find more use in >> project.el, by having `project-buffers' just call `match-buffers' with a >> special `buffer-match-p' predicate. Here is a sketch of how that could >> look like (I haven't tested it yet): > > Sure, but only after we're ready to drop project.el support for Emacs > older than 29. The functionality can be provided using Compat[0], as is already done for a few core package that are distributed on GNU ELPA (ERC, python-mode). [0] https://elpa.gnu.org/packages/compat.html >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index ac278edd40..b55c245368 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -352,15 +352,28 @@ project--remote-file-names >> (concat remote-id file)) >> local-files)))) >> +(defun project-includes-buffer-p (buffer dir) >> + "Return non-nil if the `default-directory' of BUFFER is below DIR." >> + (file-in-directory-p >> + (buffer-local-value 'default-directory buffer) >> + dir)) > > Not an optimal name, given that we have made project-buffers a generic > function, so that a custom project backend can define their own > buffer-listing strategy. And this one implies that matching by > default-directory is universal. Right, as I said this is just a sketch. But as the diff showed, I think any more specific implementation ought to extend the generic implementation, by using `cl-call-next-method' instead of `buffer-list'. >> +(defcustom project-buffer-conditions > > Why not keep considering unknown buffers as part of project by default? What are "unknown buffers"? > We'll just stop killing them on cleanup. > > Otherwise, we'll really need an extensible mechanism for major modes > all around the ecosystem to tag themselves as project-visible. Wouldn't a simple buffer local variable suffice? >> + '(and (or buffer-file-name >> + (derived-mode . compilation-mode) >> + (derived-mode . dired-mode) >> + (derived-mode . diff-mode) >> + (derived-mode . comint-mode) >> + (derived-mode . eshell-mode) >> + (derived-mode . change-log-mode)) >> + project-includes-buffer-p) >> + "A buffer predicate for matching what buffers belong to a project." >> + :type 'buffer-predicate) > > Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others. This is my point, I think Jo=C3=A3o is right that this ought to be an enumeration of major modes that are related to projects. As this is a user option, users can add or remove whatever modes they disagree on and that behaviour would ideally be propagated to all projects.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 16:24:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 12:24:10 2022 Received: from localhost ([127.0.0.1]:44078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opu3d-0000Zh-TQ for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 12:24:10 -0400 Received: from mail-oa1-f42.google.com ([209.85.160.42]:36806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1opu3b-0000ZC-4C for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 12:24:07 -0400 Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-13bef14ea06so17360076fac.3 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 09:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pOCJ/S/iKeHFhFWyrWBm8EcNIsLJR5g247UStZ+/4nU=; b=qiQNTOcKftEdX5XjZ0Gb0QW2yjcpSWkM8Z51pCLaF+vi+w5SmBPgq1iwE4d9T2kNqF qx5xX+88VYjmgY+OiNlTI5iz4EqcQTZMiFf/leh6kLGPRjsPDjMcNJLKdNFxO+UzVhtZ tJbgGZ3qGR/bT2d1p0dMCnfmb8Q7knNUfIXQukI58x/kGFogueI/pnfEBWqQ+cE1ijwP CrjRBo+n7eWlF6SielXo2l8/I+5fuYKgyX+p+ImGnDwuyIhAwh+R2haK3poCqyG1tOdp dMu+JAFl99szTf/DB2W4JxKLSuv3hEWgbeRSLoDsU4GCBTqR+CpUcKqMLThUtIKYGYzB Dhhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pOCJ/S/iKeHFhFWyrWBm8EcNIsLJR5g247UStZ+/4nU=; b=jQ+lEUR14V6/EGP+CKkXk8UME/gSSy+pDtKZRffZ67NZU0eDMEEsja9mhiwuIXKr8l SyMfeaEBvpGl6uqRi53x1CYEXJtU6vuwhc+vY6E0fntonwsP6Po0Ekk5JIDAPsFRBQhd sEwoq4shFkOhYY6SZTfdHf3Ym7jCwpYBOfMOESJkFqdUPr02IgqrT17OIEogxTGzhkZR 9Zag3aJ2ooiQKHNdzuBOndCOMGphnOp7tqGH3pE/fAp2lVx3PcmkVf0g8M9OUlqJQntF /7ZDExj9xNNLqjDc4oEBK8bCGhCDLE7bK8qJDIiYy0R/pStBsz9T5xyPDTn4IJpLAv40 NG+A== X-Gm-Message-State: ACrzQf1ZvNzB29vkKeiBNpOxT1WMBjfktldXyBK8hm5A8AbU/sLs+p+M bCGrIcx7lC5EF0DEW8EeivourzlQDefiJCDPwHI= X-Google-Smtp-Source: AMsMyM6KF7R6pob0GEyJGtyLCc3khkUZFepSS+zQN+ZUIsp9zEtk4SvydutvvLNMIluZg3+mys3kJrXNsv2v2M60nUk= X-Received: by 2002:a05:6870:e242:b0:13b:d561:ad02 with SMTP id d2-20020a056870e24200b0013bd561ad02mr11813136oac.215.1667319841292; Tue, 01 Nov 2022 09:24:01 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN> <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN> In-Reply-To: <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 16:23:48 +0000 Message-ID: <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000de061505ec6b2656" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000de061505ec6b2656 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <dgutov@HIDDEN> wrote: That's an unfair expectation: you didn't suggest an improvement either. > Oh, I'm sorry, and is it fair to inquire about the subliminally compressed: "and eglot reinvents http-url"? Can you generously grant a few more sentences as to its meaning and relevance? Much obliged, Jo=C3=A3o > --000000000000de061505ec6b2656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <<a href= =3D"mailto:dgutov@HIDDEN">dgutov@HIDDEN</a>> wrote:</div><div dir= =3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"aut= o"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> That's an unfair expectation: you didn't suggest an improvement eit= her.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au= to">Oh, I'm sorry, and is it fair to inquire about the subliminally com= pressed: "and eglot reinvents http-url"? Can you generously grant= a few more sentences as to its meaning and relevance?</div><div dir=3D"aut= o"><br></div><div dir=3D"auto">Much obliged,</div><div dir=3D"auto">Jo=C3= =A3o</div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> </blockquote></div></div></div> --000000000000de061505ec6b2656--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 15:27:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 11:27:19 2022 Received: from localhost ([127.0.0.1]:44003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1optAc-0005Nt-Uy for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:27:19 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:38566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1optAb-0005Nf-2x for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:27:18 -0400 Received: by mail-wm1-f45.google.com with SMTP id r186-20020a1c44c3000000b003cf4d389c41so10204725wma.3 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 08:27:17 -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=y6h24vSdJ9I6vPmy/YI0k8cOx4oxhWIDlpNk6aoMkDY=; b=VHiLtw3cDMowE3TgWA6mWbxkXazrl0aP7fRosIHIzfZse4pLiNHvP+ORn5SZc+YPNp 6j7FIFU3JmtfOXJKWHzOH1/ZzwYCbxlPtRzcUh24N3bDOhsq+72t4SZhCoPcWjyeQy1W WO+D9XVTRNa+DmFKRkQ9+Or4uTyQnlp5ZalwTgd5VUID/YT0fJwxxySMJs86l7Cn/IFa RTerMHvISbYr9RhRVMaCr+ViIbb9G8oo6iZxDA9wOkh4+5RCc0+2oUnUEX8nDjQR2a74 rva9+bxShunWOiICKtiY0QFQKzTAc40vS6kbvo56O5NFwv+uu0uMbhFbPgSCzNg8dBfK iJ1Q== 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=y6h24vSdJ9I6vPmy/YI0k8cOx4oxhWIDlpNk6aoMkDY=; b=GPrOFSy52Xqe/oPGZJKtxDDspLHQtBw6hb7hCGOE9gwVzgyHGcYSYwZN6zBHvrg5Kr czdASVWNLmj/hZbv31UKnJhNjkt5O/6KHHM0OyHAHIl0HuN7FnrRu9MxEvb8qT9FXDIv utwXqhMlqnAEldQdqO3/PkL6OA27IDaCLmlyCdOBiKEtrroawCpnwin0tCC5wll602VA yB//UyVEoAiEVNWVhnzYppjELAUZ/wOb9Otx4oNRAnmGe3wg7mnUZtrD7m5bLsWCYYuh +8uGyASClwhbc3PulN0M3ah0qC31zDvuPzeUUxRuR9cQRNVPHrIh+ciZd6ZSKiq/bSSR NNzQ== X-Gm-Message-State: ACrzQf2kwlb4aBSG7rQFOK/5YGE3cmuZ3G19Wfdz7Ss6FwytLohIWMKM OfuwjH304nnbisVLl+hGruE= X-Google-Smtp-Source: AMsMyM6saVuREJdkMx6ApR8HASbMBtnNHJW242r+dW4400OJYe6Z/1YCHIhzYzwGENxXSbpM0WQDDQ== X-Received: by 2002:a7b:cb49:0:b0:3b4:b08a:89b with SMTP id v9-20020a7bcb49000000b003b4b08a089bmr12185228wmj.173.1667316431391; Tue, 01 Nov 2022 08:27:11 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id az24-20020adfe198000000b0022e035a4e93sm10561908wrb.87.2022.11.01.08.27.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 08:27:11 -0700 (PDT) Message-ID: <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN> Date: Tue, 1 Nov 2022 17:27:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 13:39, João Távora wrote: > On Tue, Nov 1, 2022 at 11:23 AM Dmitry Gutov <dgutov@HIDDEN > <mailto:dgutov@HIDDEN>> wrote: > > On 01.11.2022 12:59, João Távora wrote: > > For me, it looks like match-buffers is reinventing > > cl-remove-if-not and match-buffer-p is reinventing ... unary > predicate > > function of a buffer? > > And Eglot is reinventing url-http. > > > Really? Where? I don't understand how, might it might very well be. > Can suggest an improvement? I love to kill code, so let 'er rip. That's an unfair expectation: you didn't suggest an improvement either.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 15:26:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 11:26:37 2022 Received: from localhost ([127.0.0.1]:43997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opt9x-0005M9-92 for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:26:37 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:37864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opt9v-0005Lw-1O for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:26:35 -0400 Received: by mail-wr1-f49.google.com with SMTP id bs21so20653890wrb.4 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 08:26:35 -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=L/ItkN1ALilt2KUAqidRz7Je6n38FFFwzvwNFLVHv1I=; b=HSAwaRfPaVf/FnJl9UIj5D4hg+j0Af502pyY9XnLzQxfpgarWNSXxCLboMmrE/u26F ckP4J63IgSiFRpZsNF1vkwE6ZmAgmus9xxXaYFOsObqPjgAu+//72EJ7YdopBNjDtJaM v8Na1uobYmaTJ99zOPBTMqeyN0jtBbQf50329lYyTDqtX9b88uvdYt7DGc88YSPx2fyC sDGPxwjFmY7xN4KUIw7bA9/X5KrVR+7YbEdXVPPCybo1CKtp/UoNf3Tg/jPkPhBgN5KP rAOIqJ44QYqGC7gltyZAdrGV4tJGf8l/1/Y8yEMyWEvdC3XydcPUlXJnLYxNAQ9B3QNc ffGQ== 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=L/ItkN1ALilt2KUAqidRz7Je6n38FFFwzvwNFLVHv1I=; b=xUaqAiuhto6e/18Bpo7lVYH28gJLaGymPWrQOdbGHmJtriHhXWxr+SPSc6P+UTlQ7R lwF3MZt2qiXQslz5ZxjIJXTuVJvXkDBfdw7b0F1MNiyhcsXqHJ27ciRNyue56EaPYL61 i34SM58yoHDbe9mtI+bM0sEq8AJZsTfu04VC7dAdvstAwZ8MUglIvTskBXNUxLTStk1l DnFaBGXSAgz/4OAoXZkyUUK6UUUn44cDriLiZr+60B3ZEdmDZDRcwFsvYV7D32vKa9nR obuJAq/kLdnyfF7VhdSA2vQBaSgeXPKBY8KMt1/QEW7rHRtm2/TGxSg1xfawG7odXqLE 9VFg== X-Gm-Message-State: ACrzQf3ZKOZ5pj+FtpORblKx/vmBSz0gHttdwu7ehFRUP4w4vb1ISyVD 1wHz4+fOKvBcUAzq+DvMiCE= X-Google-Smtp-Source: AMsMyM5BUFqzcKKLKKtobcNx7EDxI2u0qxc5SNOfdKsQxQ/kx6UkbfB8BrynlN7vCiB2YuTKtsOkJg== X-Received: by 2002:a5d:650b:0:b0:236:8ead:3ec2 with SMTP id x11-20020a5d650b000000b002368ead3ec2mr12176403wru.434.1667316388870; Tue, 01 Nov 2022 08:26:28 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l13-20020a05600c2ccd00b003a2f2bb72d5sm11942410wmc.45.2022.11.01.08.26.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 08:26:28 -0700 (PDT) Message-ID: <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> Date: Tue, 1 Nov 2022 17:26:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87h6zihq3q.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 13:27, Philip Kaludercic wrote: > I am biased, but I believe that the language could even find more use in > project.el, by having `project-buffers' just call `match-buffers' with a > special `buffer-match-p' predicate. Here is a sketch of how that could > look like (I haven't tested it yet): Sure, but only after we're ready to drop project.el support for Emacs older than 29. > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index ac278edd40..b55c245368 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -352,15 +352,28 @@ project--remote-file-names > (concat remote-id file)) > local-files)))) > > +(defun project-includes-buffer-p (buffer dir) > + "Return non-nil if the `default-directory' of BUFFER is below DIR." > + (file-in-directory-p > + (buffer-local-value 'default-directory buffer) > + dir)) Not an optimal name, given that we have made project-buffers a generic function, so that a custom project backend can define their own buffer-listing strategy. And this one implies that matching by default-directory is universal. > +(defcustom project-buffer-conditions Why not keep considering unknown buffers as part of project by default? We'll just stop killing them on cleanup. Otherwise, we'll really need an extensible mechanism for major modes all around the ecosystem to tag themselves as project-visible. > + '(and (or buffer-file-name > + (derived-mode . compilation-mode) > + (derived-mode . dired-mode) > + (derived-mode . diff-mode) > + (derived-mode . comint-mode) > + (derived-mode . eshell-mode) > + (derived-mode . change-log-mode)) > + project-includes-buffer-p) > + "A buffer predicate for matching what buffers belong to a project." > + :type 'buffer-predicate) Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 14:36:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 10:36:54 2022
Received: from localhost ([127.0.0.1]:43975 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opsNq-00047K-1l
for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:36:54 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39209)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <philipk@HIDDEN>) id 1opsNo-000478-6S
for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:36:53 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id A658D240028
for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 15:36:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1667313406; bh=jvwBwx3y90+U9jOkSychBOnmFaZEDA+3leADCfEbYJU=;
h=From:To:Cc:Subject:Autocrypt:Date:From;
b=bM+tmHl2xk9NbRSKNWww2Xljb9rMFcBYBVrJuhw0CLo3oiolQTy4lwZOkTwr5uOfF
BGU/qd2rNUJlMH3Qh1hm2OhAM968rK+Id7/Nim8g5B24xqlF3X752YmEiyZjScND3B
w8br5QAU/GZ9mRiRqiJe4lmkXnlpt2xGamm9FYheSub6UbtVMU63MFuhwldDVlL3CL
1EvDbBmNzB2ZppIvamX3Gf4byGThzHwcDG6IGdFPJyzl0X/vOOhLvqL5IbqYyi06Q1
uyoWWHdHmWx9ot8W3/AwSx3dkP5OCKqusECyo2oozQ/U+BqIr6IpjoYD4SEnRvyfxZ
oSiHwCX6xvTkA==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4N1szK0bFHz9rxV;
Tue, 1 Nov 2022 15:36:42 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
(=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 1 Nov 2022
14:11:35 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
<87h6zihq3q.fsf@HIDDEN>
<CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
<877d0ehlnb.fsf@HIDDEN>
<CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
<87edumg4fd.fsf@HIDDEN>
<CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 14:36:42 +0000
Message-ID: <874jvig2rp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> On Tue, Nov 1, 2022 at 2:00 PM Philip Kaludercic <philipk@HIDDEN> wro=
te:
>
>
>> > My idea of using the byte-compiler to do this is different: it entails
>> > translating the mini-language to elisp first and then byte-compiling
>> > that. But it is a technique that I think your code isn't applying
>> > or at least not correctly (though I haven't read all of it: I will soo=
n).
>>
>> What I am doing is translating it into lambda expressions, but I could
>> also try out translating it into an s-expression and passing that to
>> `eval'...
>>
>
> Yes, do that, but use byte-compile instead, not eval.
I have tried both, and it doesn't appear to be a particular advantage
one way or another. That being said, this approach is *a lot* faster,
to the point that I first assumed it was broken:
--8<---------------cut here---------------start------------->8---
(benchmark-run 1000
(match-buffers/compiled sample-condition))
;; (0.469515746 5 0.3328363100000047)
--8<---------------cut here---------------end--------------->8---
but it works:
--8<---------------cut here---------------start------------->8---
(equal (match-buffers sample-condition) (match-buffers/compiled sample-cond=
ition))
;; =3D> t
--8<---------------cut here---------------end--------------->8---
So this is certainly something worth considering as a replacement!
Here is the implementation:
--8<---------------cut here---------------start------------->8---
(defvar translate-buffer-condition-buffer-sym (make-symbol "buffer"))
(defvar translate-buffer-condition-arg-sym (make-symbol "arg"))
(defun translate-buffer-condition (condition)
"Compile a CONDITION into a predicate function."
(pcase-exhaustive condition
((or 't 'nil)
condition)
((pred stringp)
`(string-match-p ,condition (buffer-name ,translate-buffer-condition-b=
uffer-sym)))
((pred functionp)
(if (eq 1 (cdr (func-arity condition)))
;; FIXME: is `funcall' necessary here?
`(funcall #',condition ,translate-buffer-condition-buffer-sym)
`(funcall ,condition
,translate-buffer-condition-buffer-sym
,translate-buffer-condition-arg-sym)))
(`(major-mode . ,mode)
`(eq (buffer-local-value 'major-mode ,translate-buffer-condition-buffe=
r-sym)
',mode))
(`(derived-mode . ,mode)
`(provided-mode-derived-p
(buffer-local-value 'major-mode ,translate-buffer-condition-buffer-s=
ym)
',mode))
(`(not . ,cond)
`(not ,(translate-buffer-condition cond)))
(`(or . ,conds)
`(or ,@(mapcar #'translate-buffer-condition conds)))
(`(and . ,conds)
`(and ,@(mapcar #'translate-buffer-condition conds)))))
(defvar buffer-match-p-cache (make-hash-table :test 'eq))
(defun buffer-match-p/evaled (condition buffer-or-name &optional arg)
"Return non-nil if BUFFER-OR-NAME matches CONDITION.
CONDITION is either:
- the symbol t, to always match,
- the symbol nil, which never matches,
- a regular expression, to match a buffer name,
- a predicate function that takes a buffer object and ARG as
arguments, and returns non-nil if the buffer matches,
- a cons-cell, where the car describes how to interpret the cdr.
The car can be one of the following:
* `derived-mode': the buffer matches if the buffer's major mode
is derived from the major mode in the cons-cell's cdr.
* `major-mode': the buffer matches if the buffer's major mode
is eq to the cons-cell's cdr. Prefer using `derived-mode'
instead when both can work.
* `not': the cdr is interpreted as a negation of a condition.
* `and': the cdr is a list of recursive conditions, that all have
to be met.
* `or': the cdr is a list of recursive condition, of which at
least one has to be met."
(eval (or (gethash condition buffer-match-p-cache)
(puthash condition
(translate-buffer-condition condition)
buffer-match-p-cache))
`((,translate-buffer-condition-buffer-sym . ,(get-buffer buffer-or-name))
(,translate-buffer-condition-arg-sym . ,arg))))
;; Alternative implementation using `byte-compile':
;;
;; (funcall (or (gethash condition buffer-match-p-cache)
;; (puthash condition
;; (byte-compile
;; `(lambda (,translate-buffer-condition-buffer-sym
;; ,translate-buffer-condition-arg-sym)
;; ,(translate-buffer-condition condition)))
;; buffer-match-p-cache))
;; (get-buffer buffer-or-name) arg)
--8<---------------cut here---------------end--------------->8---
In the end, the second implementation using `byte-compile' might be
preferable as it avoids using `eval'.
> Jo=C3=A3o T=C3=A1vora
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 14:10:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 10:10:44 2022 Received: from localhost ([127.0.0.1]:43946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opryW-0003TA-8h for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:10:44 -0400 Received: from mail-oo1-f50.google.com ([209.85.161.50]:34605) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1opryU-0003Sv-F6 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:10:43 -0400 Received: by mail-oo1-f50.google.com with SMTP id v8-20020a4ab688000000b00486ac81143fso2070898ooo.1 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 07:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QzpGtOu9iOOwpnGNjAbO1oAqS6AwgrA16djs3xyMpnA=; b=V6EO7q3lXACIgNB+gUevmhGSTL1/DvHg+NXfUeQMkr03aJ9Ga0f2LWew6nwkTja1mu 7kKoXvKPXCsWDJAdecVDPbTa9KauXsE5zdfwhOly57/diP1WfHX7u55/AntiDzJs3DQO j2zBDsTW5TrnWSfAYfOEqhng6u76DpZW1KtcNZa7tLNvFzMn9uiboP4zczAoKH/Z3dNy ASxiSVdG2PZro+MbLXDl+tohRn1B9R5U8SfAmwr+FnVEKh3tlzpfULKLSJJrMURvz5eb N1sC9Nn83LtGbWLu90lRZUaHWgvZu0K0BmnaVeTu+xusC4BSjkLTOup3dslnbBAma1v7 zArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QzpGtOu9iOOwpnGNjAbO1oAqS6AwgrA16djs3xyMpnA=; b=K0aS/9RF2lKENJJZqm7w5NfDCRDWcfGUBSjzX9/h1KekOmkaGA/hu63CGYryoo2AZP 7JNmvL+IBWsZ49kf2PssW+b+BvN1Nwe4Pdy6O6Cvu/3r1e0W5hg06VLiLYrm/m38badu bRfPlmRZyPK38sCDhUJZENnUD+7hSdDNB08eH5D3YnsJmvNncMBARrRUuFuAj0J1ubvv hpHPKU+k2ncm6sgn3/X+9wEsAOkpneAX0WZ0ahywOoKu9gjJJNLlc61MTKjM9ayyroA2 RAXXb5Q02Xy89bgkJjTkwmoUVaSfGbsW8Ela8t+Oomo+Mvu+1VsI/6Erib8kpJok/emA p/EQ== X-Gm-Message-State: ACrzQf0vpVNra2Z2qkqh/e/MjIMR8FypB5YDumHgj+kCLSNXDr+W7g37 2uL/umTepqVO6sfOSdFzHghx3byyUK76l3BWiw8= X-Google-Smtp-Source: AMsMyM6C/IwwLSoQ2i7OThpf6pbSwITgN1ynMSuBd+zXPNFLIdOCnGzKg05Uc5sLXE8ALv+l8spTJ08h4C4XV5ssFbY= X-Received: by 2002:a4a:7:0:b0:495:f4a4:4bdc with SMTP id 7-20020a4a0007000000b00495f4a44bdcmr8114923ooh.41.1667311836895; Tue, 01 Nov 2022 07:10:36 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> <87edumg4fd.fsf@HIDDEN> In-Reply-To: <87edumg4fd.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 14:11:35 +0000 Message-ID: <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000c49f2605ec694965" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000c49f2605ec694965 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022 at 2:00 PM Philip Kaludercic <philipk@HIDDEN> wrote= : > > My idea of using the byte-compiler to do this is different: it entails > > translating the mini-language to elisp first and then byte-compiling > > that. But it is a technique that I think your code isn't applying > > or at least not correctly (though I haven't read all of it: I will soon= ). > > What I am doing is translating it into lambda expressions, but I could > also try out translating it into an s-expression and passing that to > `eval'... > Yes, do that, but use byte-compile instead, not eval. Jo=C3=A3o T=C3=A1vora --000000000000c49f2605ec694965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Tue, Nov 1, 2022 at 2:00 PM Philip Kaludercic <<a href=3D"mail= to:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > My idea of using the byte-compiler to do this is different: it entails= <br> > translating the mini-language to elisp first and then byte-compiling<b= r> > that.=C2=A0 But it is a technique that I think your code isn't app= lying<br> > or at least not correctly (though I haven't read all of it: I will= soon).<br> <br> What I am doing is translating it into lambda expressions, but I could<br> also try out translating it into an s-expression and passing that to<br> `eval'...<br></blockquote><div><br></div><div>Yes, do that, but use byt= e-compile instead, not eval. <br></div><div><br></div></div><div dir=3D"ltr= " class=3D"gmail_signature">Jo=C3=A3o T=C3=A1vora</div></div> --000000000000c49f2605ec694965--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 14:01:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 10:01:04 2022 Received: from localhost ([127.0.0.1]:43941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oprpA-0003GD-5e for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:01:04 -0400 Received: from mout02.posteo.de ([185.67.36.66]:60671) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oprp7-0003FZ-7I for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:01:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 73BF0240104 for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 15:00:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667311255; bh=5EVYzVr8SRK6BFjdPIb5C+crEl8LXYBRXsj8pIZCzjA=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=HXrPloGg8+e5vWftbVpxYsAcoGWG2HkTZsYADL9qhG4oF3zWxh7X8HNrssq8Ogxvx K4OhKrqCE821EOm2eH8wJpn/W7MqHnlahfAw7xuI8JdRxYNs7GPhz8mfqn7p8iu/qg g4fBG4u3OUyjrar0naSmEVuCPU9SQW3/KAF0s2rJt+uVx+EUKcU7dgfacHIE1yGUO3 fj+f/qIw2i884xseTyYb/vhuMx78Q8ZbAgfqHlDs3CrBmIjDRYdOiZ6Zk16ZI29FAx +3FRW0/L1B+qlBuZE3UliZfLH2ZIxzPZg0UagZohnhFP0nUIcPENq97LAWbwIvpp/w yd+uVUxef6dgA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1s9y3196z9rxY; Tue, 1 Nov 2022 15:00:54 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 1 Nov 2022 13:37:58 +0000") References: <87sfj8umwb.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Tue, 01 Nov 2022 14:00:54 +0000 Message-ID: <87edumg4fd.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > I haven't studied your code in depth, but it seems like you're giving > `match-buffers/compiled` benchmark 10 times the work you're giving to > the other function, which would explain why it's 10x slower. > You are absolutely right, I re-ran the tests the right way and got these results: --8<---------------cut here---------------start------------->8--- (benchmark-run 1000 (match-buffers sample-condition)) ;; =3D> (25.052781603 265 16.678798381999997) (benchmark-run 1000 (match-buffers/compiled sample-condition)) ;; (30.021295067 335 21.01291473699999) --8<---------------cut here---------------end--------------->8--- > The byte-compiler (or the native compiler) can't really optimize the > mini-language more magically. It can only optimize elisp. Of course, I don't get why it should? > My idea of using the byte-compiler to do this is different: it entails > translating the mini-language to elisp first and then byte-compiling > that. But it is a technique that I think your code isn't applying > or at least not correctly (though I haven't read all of it: I will soon). What I am doing is translating it into lambda expressions, but I could also try out translating it into an s-expression and passing that to `eval'... > You can see eglot's "glob matching" section for the application of > such a technique the "glob" minilanguage that is required by LSP (iow > it wasn't "invented by me" ;-) )
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:38:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 09:38:15 2022 Received: from localhost ([127.0.0.1]:42956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oprT4-0002PU-VU for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:38:15 -0400 Received: from mail-oa1-f46.google.com ([209.85.160.46]:33686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oprT3-0002PH-On for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:38:14 -0400 Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-13bd2aea61bso16868431fac.0 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 06:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vHc9DcZ5LRcp6WiUPIRkf4ktgh7G+pHsBpMQX3uIVnI=; b=cp7QcXccTkaTbHdRpmFrC6sSu/UIHUOGbkI1atlEVf/vp3BSd1rc4+Hd3SgtjqLgb1 Z+23PkCXgfOloeN3UzmfyXOxnq2uAY4SBPtp00Z+vweE531kYSI/h4lot6DquN5bbl8d 3d+NJuP3QzT+yQK8eFRm42O/vo0GEUck4kDj7DOoQIgc/SGlLrZjHtcmGl8/+JjhB3Fu pUNHgwvyGNF9NTN2tU+xXDRt4haVBOxSt/VOgNumDu96lWHUd0aBbkaF1COV+7UX7FVf 4kSpXmxrzby3MfG0fLZSq6wao7MBjt9P+mWOBH0HyNRa+LcQx/8psG4/9r8j9cKLLT6W fv6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vHc9DcZ5LRcp6WiUPIRkf4ktgh7G+pHsBpMQX3uIVnI=; b=IQqyITBseQUIn9ajQsAMNV6XxP2PtKJ08x9Y92aCj8rwUsGL+VHAQ4yZMmRlWeNbCw Th7zyXg8AzB6ioLfxeXoevFNBoJ6lNSRcfuVtbV54YtxUboGBo3kS7YZrh9a+pBVVjXz 8N8kLGSu4pd5oyqjPR22+34PTfX+LhA8Mbmra4Nr4AbbVlf6mlbndiAA4L0g8oi5M93H PdFlOGqIjlkSfYzwlhc7z/lWsTw8OCHKwkY6BU9RSi7Rc41TcwxZjlexdP0djcxiwxqv iLqqRRgTDvpwBIoun8eXqqvPJtgTlc0vmEAPBITo6DWaclfpLKRhZw7dOi4XVvZFNheF r/CA== X-Gm-Message-State: ACrzQf1xMVeHK8WdFw8JLn/d/mm/2fiV8xaVH6LUXjFbePJJMa6034fO 7nzKROMHuqhY7OlGxx6ST+KnSyKuEIBmRW88rLQ= X-Google-Smtp-Source: AMsMyM5eGntpjLBp9j2IuK5wbR/ZJO9HnQMKa6xLWAh0RrxvUnir59AmpylqeNnSd7v2GBDpGxOf9+KfyGay6fasTlY= X-Received: by 2002:a05:6870:e242:b0:13b:d561:ad02 with SMTP id d2-20020a056870e24200b0013bd561ad02mr11297714oac.215.1667309888295; Tue, 01 Nov 2022 06:38:08 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN> <875yfzvawz.fsf@HIDDEN> <351398ad-1292-f366-3adf-f86a129f9c90@HIDDEN> In-Reply-To: <351398ad-1292-f366-3adf-f86a129f9c90@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 13:39:05 +0000 Message-ID: <CALDnm51rxRsMrZ7Nt-E_cLJryzMD0xx9qkHxmjOoctQNxn-m6g@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000009f58a305ec68d565" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000009f58a305ec68d565 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022 at 1:22 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > On 01.11.2022 01:19, Jo=C3=A3o T=C3=A1vora wrote: > > We can try to make some backward compatible way, but this seems like th= e > > perfect occasion to activate this most reasonable header in project.el: > > > > ;; NOTE: The project API is still experimental and can change in > major, > > ;; backward-incompatible ways. Everyone is encouraged to try it, > and > > ;; report to us any problems or use cases we hadn't anticipated, b= y > > ;; sending an email to emacs-devel, or `M-x report-emacs-bug'. > > This is about the API. > > project-kills-buffers is not part of it. It's just a regular user-level > command, to be evolved how we do with regular commands. project-kill-buffers is great: I don't mean to deprecate it change it, its protocol etc. If "evolution" means fixing what are demonstrably its very salient bugs, that's great. Philip's worry was about project-kill-buffer-conditions. That variable contains a programming language and could be deprecated (if we arrive at the conclusion that it is easily replaced by something else). We shouldn't be shy of doing so a backward-incompatible way, given that its usage is estimated to be minimal (and this estimation is backed up by real data, not just a guess). --0000000000009f58a305ec68d565 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Tue, Nov 1, 2022 at 1:22 PM Dmitry Gutov <<a href=3D"mailto:dg= utov@HIDDEN">dgutov@HIDDEN</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">On 01.11.2022 01:19, Jo=C3=A3o T=C3=A1vora= wrote:<br> > We can try to make some backward compatible way, but this seems like t= he<br> > perfect occasion to activate this most reasonable header in project.el= :<br> > <br> >=C2=A0 =C2=A0 =C2=A0 ;; NOTE: The project API is still experimental and= can change in major,<br> >=C2=A0 =C2=A0 =C2=A0 ;; backward-incompatible ways.=C2=A0 Everyone is e= ncouraged to try it, and<br> >=C2=A0 =C2=A0 =C2=A0 ;; report to us any problems or use cases we hadn&= #39;t anticipated, by<br> >=C2=A0 =C2=A0 =C2=A0 ;; sending an email to emacs-devel, or `M-x report= -emacs-bug'.<br> <br> This is about the API.<br> <br> project-kills-buffers is not part of it. It's just a regular user-level= <br> command, to be evolved how we do with regular commands.</blockquote></div><= div><br></div><div></div><div>project-kill-buffers is great: I don't me= an to deprecate it change it, <br></div><div>its protocol etc.=C2=A0 If &qu= ot;evolution" means fixing what are demonstrably <br></div><div>its ve= ry salient bugs, that's great.<br></div><div><br></div><div>Philip'= s worry was about project-kill-buffer-conditions.=C2=A0 That variable <br><= /div><div>contains a programming language and could be deprecated (if we <b= r></div><div>arrive at the conclusion that it is easily replaced by somethi= ng else).</div><div>We shouldn't be shy of doing so a backward-incompat= ible way, given that</div><div>its usage is estimated to be minimal (and th= is estimation is backed up</div><div>by real data, not just a guess).<br></= div></div> --0000000000009f58a305ec68d565--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:37:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 09:37:09 2022 Received: from localhost ([127.0.0.1]:42952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oprS0-0002Nl-QQ for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:37:09 -0400 Received: from mail-oo1-f54.google.com ([209.85.161.54]:42842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oprRy-0002NE-Fz for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:37:07 -0400 Received: by mail-oo1-f54.google.com with SMTP id r15-20020a4abf0f000000b004761c7e6be1so2059109oop.9 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 06:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8HwEpsuoNpnl+CBW7x367l71OL2U0dWXqTtQidV6DdM=; b=eLYCzpky9vSFTl2w2/x1tc/DlXrN9vzL6E4ksMfLIZsj4tyiqYAQyScDCB0vVXRLi5 +foxMIvddvalGQioMQ/yZCJaRMbaoGcMvPBSWJH5zh/FeFMNX2+D53QwtZNHvrRDkPDe otMOZ9Ks+1rP9V+u6dfosO+avuili+3EUi4Ey0kAEzEIuVq69rawR8SyOS9kBi0jd4R2 mfTvL64FuIiPeMhxoVH+0OXeJee5qwDut8dfOl8KykMBVVng6w1R+iDQkv3ujv7YbXTJ sqgIiq4A3MJaqql/C8L/CanXNCohFcCxK/YXE3/ND8xjr4P+PLwpsrrrjLM6iTsDtSTb ErUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8HwEpsuoNpnl+CBW7x367l71OL2U0dWXqTtQidV6DdM=; b=crT0hggrXeDN00ra6POFNwQF9IMgTuff7S+Bn+Qz0IztPXwas713GGyTOKL6/03iGg 4Lj4O2Qpc7z3zdhuW8H5266B0jaL+Pb6g+FGSnOFxubJHqul2dgeGgwyammHpuwRNJvq 2VdMh0YB7Jk9/Hq8Y8ZxpTdZAsOvT2KMPrhPWClFs6jgl4tl4kqiEI7Afc4ch73ej061 9WmFQ+Xe3AQsbZNg54lLfkcLpA3IaVQLjKFm2OAXywe2CyNTYEWj1ERxmkQeILyfPrDW fl+/QO63QxhIUncC1B6znfZLPGNqhFIJtUfIao/7cAGccQRV6TF2y/LVo5c75/n2Gl4S 6wmA== X-Gm-Message-State: ACrzQf1m2U0Dt1nRVYgyfVN6/G1uW6Su7Bclwl7ZS9T4APIBYn5CTqq5 bg62Gu5WIuVSIHbyP7IifXa9N2u7IuCQ0Nfpvj8= X-Google-Smtp-Source: AMsMyM7G1tSUUpctpfnDfj+fKi/5XQ27jExVbXSYJwTs+zZlRtTfAgM7eXAtMNq3xOALXqhdHK14lNX9fxrjOBFIdxE= X-Received: by 2002:a4a:7:0:b0:495:f4a4:4bdc with SMTP id 7-20020a4a0007000000b00495f4a44bdcmr8047669ooh.41.1667309820483; Tue, 01 Nov 2022 06:37:00 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <87h6zihq3q.fsf@HIDDEN> <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN> <877d0ehlnb.fsf@HIDDEN> In-Reply-To: <877d0ehlnb.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 13:37:58 +0000 Message-ID: <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000949d9f05ec68d1db" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000949d9f05ec68d1db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't studied your code in depth, but it seems like you're giving `match-buffers/compiled` benchmark 10 times the work you're giving to the other function, which would explain why it's 10x slower. The byte-compiler (or the native compiler) can't really optimize the mini-language more magically. It can only optimize elisp. My idea of using the byte-compiler to do this is different: it entails translating the mini-language to elisp first and then byte-compiling that. But it is a technique that I think your code isn't applying or at least not correctly (though I haven't read all of it: I will soon). You can see eglot's "glob matching" section for the application of such a technique the "glob" minilanguage that is required by LSP (iow it wasn't "invented by me" ;-) ) Jo=C3=A3o On Tue, Nov 1, 2022 at 1:03 PM Philip Kaludercic <philipk@HIDDEN> wrote= : > Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > > > On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@HIDDEN> > > wrote: > > > > > >> E.g. `display-buffer-alist' makes use of it to associate display-buffe= r > >> rules with buffers. Now you can add > >> > >> ((major-mode . help-mode) display-buffer-in-side-window) > >> > >> instead of trying to match being a regular expression to catch all > >> *Help* buffer names of a function along the lines of > >> > >> (lambda (buf _alist) > >> (with-current-buffer buf > >> (derived-mode-p 'help-mode))) > >> > > > > If you really want to save up on this typing, it's better to define > > a reusable helper function, or even a higher order function. > > > > (defun buffer-mode-matcher (mode) > > (lambda (b _alist) > > (with-current-buffer b (derived-mode-p 'help-mode)))) > > > > You can add buffer-mode-matcher to the library if it becomes > > useful enough. Then you add: > > > > `(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window) > > > > to display-buffer-alist. > > > > But if you really want a new language your language, then I suggest > > a simple adapter buffer-matcher utility that merges the two. That way > one > > doesn't couple existing utilities to the new mini-language and > > simultaneously > > the new mini-language become useful in a much wider setting for those w= ho > > appreciate such things. > > > > (defun buffer-matcher (condition) > > "Return unary predicate of a buffer matching the CONDITION > > mini-language." > > (lambda (buf &rest _whatever) ; make it even more lax > > (buffer-match-p condition))) > > > > Later on, you might even pass an (... &optional compiled) so that the > > return value > > is syntax checked and optimized in some way at compile time. > > > > IOW, (E)Lisp already gives you the tools for these composition without > > needing to invent new languages with the drawbacks I listed. > > I was curious to try this out, and implemented something along the lines > of your suggestion. The bad news is that it is at least 10 times slower > than the current implementation, that isn't even really optimised. > Perhaps I did something native and didn't see what is wrong, but here > are my notes: > > --8<---------------cut here---------------start------------->8--- > (defun translate-buffer-condition (condition) > "Compile a CONDITION into a predicate function." > (pcase-exhaustive condition > ((or 't 'nil) > (lambda (_buffer _arg) > condition)) > ((pred stringp) > (lambda (buffer _arg) > (string-match-p condition (buffer-name buffer)))) > ((pred functionp) > (if (eq 1 (cdr (func-arity condition))) > (lambda (buffer _arg) > (funcall condition buffer)) > condition)) > (`(major-mode . ,mode) > (lambda (buffer _arg) > (eq > (buffer-local-value 'major-mode buffer) > mode))) > (`(derived-mode . ,mode) > (lambda (buffer _arg) > (provided-mode-derived-p > (buffer-local-value 'major-mode buffer) > mode))) > (`(not . ,cond) > (lambda (buffer arg) > (not (funcall (translate-buffer-condition cond) buffer arg)))) > (`(or . ,conds) > (lambda (buffer arg) > (catch 'match > (dolist (cond conds) > (when (funcall (translate-buffer-condition cond) buffer arg) > (throw 'match t)))))) > (`(and . ,conds) > (lambda (buffer arg) > (catch 'match > (dolist (cond conds t) > (when (funcall (translate-buffer-condition cond) buffer arg) > (throw 'match nil)))))))) > > (defvar buffer-match-p-cache (make-hash-table :test 'eq)) > > (defun buffer-match-p/compiled (condition buffer-or-name &optional arg) > "Return non-nil if BUFFER-OR-NAME matches CONDITION. > CONDITION is either: > - the symbol t, to always match, > - the symbol nil, which never matches, > - a regular expression, to match a buffer name, > - a predicate function that takes a buffer object and ARG as > arguments, and returns non-nil if the buffer matches, > - a cons-cell, where the car describes how to interpret the cdr. > The car can be one of the following: > * `derived-mode': the buffer matches if the buffer's major mode > is derived from the major mode in the cons-cell's cdr. > * `major-mode': the buffer matches if the buffer's major mode > is eq to the cons-cell's cdr. Prefer using `derived-mode' > instead when both can work. > * `not': the cdr is interpreted as a negation of a condition. > * `and': the cdr is a list of recursive conditions, that all have > to be met. > * `or': the cdr is a list of recursive condition, of which at > least one has to be met." > (funcall (or (gethash condition buffer-match-p-cache) > (puthash condition > (byte-compile (translate-buffer-condition > condition)) > buffer-match-p-cache)) > (get-buffer buffer-or-name) > arg)) > > (defun match-buffers/compiled (condition &optional buffers arg) > "Return a list of buffers that match CONDITION. > See `buffer-match' for details on CONDITION. By default all > buffers are checked, this can be restricted by passing an > optional argument BUFFERS, set to a list of buffers to check. > ARG is passed to `buffer-match', for predicate conditions in > CONDITION." > (let (bufs) > (dolist (buf (or buffers (buffer-list))) > (when (buffer-match-p/compiled condition (get-buffer buf) arg) > (push buf bufs))) > bufs)) > > ;; Here we will test a moderately complicated condition and time how > ;; long it takes with the current implementation and with the proposed > ;; alternative. > > (defvar sample-condition > '(and (or buffer-file-name > (derived-mode . compilation-mode) > (derived-mode . dired-mode) > (derived-mode . diff-mode) > (derived-mode . comint-mode) > (derived-mode . eshell-mode) > (derived-mode . change-log-mode)) > "\\*.+\\*" > (not . "\\` "))) > > (benchmark-run 100 > (match-buffers sample-condition pr)) > ;; =3D> (1.7045469830000002 20 1.1418286690000023) > > > (benchmark-run 1000 > (match-buffers/compiled project-buffer-conditions pr)) > ;; =3D> (17.646938126000002 219 12.428946030999999) > --8<---------------cut here---------------end--------------->8--- > > I guess this just goes to show that one shouldn't underestimate the cost > of a function call... > > LISP programmers know the value of everything and the cost of nothing= . > -- Alan Perlis > --=20 Jo=C3=A3o T=C3=A1vora --000000000000949d9f05ec68d1db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I haven't studied your code in depth, but it seem= s like you're giving</div><div>`match-buffers/compiled` benchmark 10 ti= mes the work you're giving to <br></div><div>the other function, which = would explain why it's 10x slower.</div><div><br></div><div>The byte-co= mpiler (or the native compiler) can't really optimize the <br></div><di= v>mini-language more magically.=C2=A0 It can only optimize elisp.</div><div= ><br></div><div>My idea of using the byte-compiler to do this is different:= it entails <br></div><div>translating the mini-language to elisp first and= then byte-compiling <br></div><div>that.=C2=A0 But it is a technique that = I think your code isn't applying <br></div><div>or at least not correct= ly (though I haven't read all of it: I will soon).</div><div><br></div>= <div>You can see eglot's "glob matching" section for the appl= ication of <br></div><div>such a technique the "glob" minilanguag= e that is required by LSP (iow <br></div><div>it wasn't "invented = by me" ;-) )<br></div><div></div><div><br></div><div>Jo=C3=A3o<br></di= v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr= ">On Tue, Nov 1, 2022 at 1:03 PM Philip Kaludercic <<a href=3D"mailto:ph= ilipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= rgb(204,204,204);padding-left:1ex">Jo=C3=A3o T=C3=A1vora <<a href=3D"ma= ilto:joaotavora@HIDDEN" target=3D"_blank">joaotavora@HIDDEN</a>> w= rites:<br> <br> > On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <<a href=3D"mailt= o:philipk@HIDDEN" target=3D"_blank">philipk@HIDDEN</a>><br> > wrote:<br> ><br> ><br> >> E.g. `display-buffer-alist' makes use of it to associate displ= ay-buffer<br> >> rules with buffers.=C2=A0 Now you can add<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0((major-mode . help-mode) display-buffer= -in-side-window)<br> >><br> >> instead of trying to match being a regular expression to catch all= <br> >> *Help* buffer names of a function along the lines of<br> >><br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda (buf _alist)<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(with-current-buffer buf<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(derived-mode-p 'help-= mode)))<br> >><br> ><br> > If you really want to save up on this typing, it's better to defin= e<br> > a reusable helper function, or even a higher order function.<br> ><br> >=C2=A0 =C2=A0(defun buffer-mode-matcher (mode)<br> >=C2=A0 =C2=A0 =C2=A0(lambda (b _alist)<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(with-current-buffer b (derived-mode-p '= help-mode))))<br> ><br> > You can add buffer-mode-matcher to the library if it becomes<br> > useful enough.=C2=A0 Then you add:<br> ><br> >=C2=A0 =C2=A0`(,(buffer-mode-matcher 'help-mode) display-buffer-in-= side-window)<br> ><br> > to display-buffer-alist.<br> ><br> > But if you really want a new language your language, then I suggest<br= > > a simple adapter buffer-matcher utility that merges the two.=C2=A0 Tha= t way one<br> > doesn't couple existing utilities to the new mini-language and<br> > simultaneously<br> > the new mini-language become useful in a much wider setting for those = who<br> > appreciate such things.<br> ><br> >=C2=A0 =C2=A0(defun buffer-matcher (condition)<br> >=C2=A0 =C2=A0 =C2=A0 "Return unary predicate of a buffer matching = the CONDITION<br> > mini-language."<br> >=C2=A0 =C2=A0 =C2=A0(lambda (buf &rest _whatever) ; make it even mo= re lax<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-match-p condition)))<br> ><br> > Later on, you might even pass an (... &optional compiled) so that = the<br> > return value<br> > is syntax checked and optimized in some way at compile time.<br> ><br> > IOW, (E)Lisp already gives you the tools for these composition without= <br> > needing to invent new languages with the drawbacks I listed.<br> <br> I was curious to try this out, and implemented something along the lines<br= > of your suggestion.=C2=A0 The bad news is that it is at least 10 times slow= er<br> than the current implementation, that isn't even really optimised.<br> Perhaps I did something native and didn't see what is wrong, but here<b= r> are my notes:<br> <br> --8<---------------cut here---------------start------------->8---<br> (defun translate-buffer-condition (condition)<br> =C2=A0 "Compile a CONDITION into a predicate function."<br> =C2=A0 (pcase-exhaustive condition<br> =C2=A0 =C2=A0 ((or 't 'nil)<br> =C2=A0 =C2=A0 =C2=A0(lambda (_buffer _arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0condition))<br> =C2=A0 =C2=A0 ((pred stringp)<br> =C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0(string-match-p condition (buffer-name buffer)))= )<br> =C2=A0 =C2=A0 ((pred functionp)<br> =C2=A0 =C2=A0 =C2=A0(if (eq 1 (cdr (func-arity condition)))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(funcall condition buffer))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0condition))<br> =C2=A0 =C2=A0 (`(major-mode . ,mode)<br> =C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0(eq<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-local-value 'major-mode buffer)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mode)))<br> =C2=A0 =C2=A0 (`(derived-mode . ,mode)<br> =C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0(provided-mode-derived-p<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-local-value 'major-mode buffer)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 mode)))<br> =C2=A0 =C2=A0 (`(not . ,cond)<br> =C2=A0 =C2=A0 =C2=A0(lambda (buffer arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0(not (funcall (translate-buffer-condition cond) = buffer arg))))<br> =C2=A0 =C2=A0 (`(or . ,conds)<br> =C2=A0 =C2=A0 =C2=A0(lambda (buffer arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0(catch 'match<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(dolist (cond conds)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (funcall (translate-buffer-c= ondition cond) buffer arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(throw 'match t))))))<b= r> =C2=A0 =C2=A0 (`(and . ,conds)<br> =C2=A0 =C2=A0 =C2=A0(lambda (buffer arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0(catch 'match<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(dolist (cond conds t)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (funcall (translate-buffer-c= ondition cond) buffer arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(throw 'match nil))))))= ))<br> <br> (defvar buffer-match-p-cache (make-hash-table :test 'eq))<br> <br> (defun buffer-match-p/compiled (condition buffer-or-name &optional arg)= <br> =C2=A0 "Return non-nil if BUFFER-OR-NAME matches CONDITION.<br> CONDITION is either:<br> - the symbol t, to always match,<br> - the symbol nil, which never matches,<br> - a regular expression, to match a buffer name,<br> - a predicate function that takes a buffer object and ARG as<br> =C2=A0 arguments, and returns non-nil if the buffer matches,<br> - a cons-cell, where the car describes how to interpret the cdr.<br> =C2=A0 The car can be one of the following:<br> =C2=A0 * `derived-mode': the buffer matches if the buffer's major m= ode<br> =C2=A0 =C2=A0 is derived from the major mode in the cons-cell's cdr.<br= > =C2=A0 * `major-mode': the buffer matches if the buffer's major mod= e<br> =C2=A0 =C2=A0 is eq to the cons-cell's cdr.=C2=A0 Prefer using `derived= -mode'<br> =C2=A0 =C2=A0 instead when both can work.<br> =C2=A0 * `not': the cdr is interpreted as a negation of a condition.<br= > =C2=A0 * `and': the cdr is a list of recursive conditions, that all hav= e<br> =C2=A0 =C2=A0 to be met.<br> =C2=A0 * `or': the cdr is a list of recursive condition, of which at<br= > =C2=A0 =C2=A0 least one has to be met."<br> =C2=A0 (funcall (or (gethash condition buffer-match-p-cache)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(puthash condition<b= r> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (byte-compile (translate-buffer-condition condition))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 buffer-match-p-cache))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(get-buffer buffer-or-name)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg))<br> <br> (defun match-buffers/compiled (condition &optional buffers arg)<br> =C2=A0 "Return a list of buffers that match CONDITION.<br> See `buffer-match' for details on CONDITION.=C2=A0 By default all<br> buffers are checked, this can be restricted by passing an<br> optional argument BUFFERS, set to a list of buffers to check.<br> ARG is passed to `buffer-match', for predicate conditions in<br> CONDITION."<br> =C2=A0 (let (bufs)<br> =C2=A0 =C2=A0 (dolist (buf (or buffers (buffer-list)))<br> =C2=A0 =C2=A0 =C2=A0 (when (buffer-match-p/compiled condition (get-buffer b= uf) arg)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (push buf bufs)))<br> =C2=A0 =C2=A0 bufs))<br> <br> ;; Here we will test a moderately complicated condition and time how<br> ;; long it takes with the current implementation and with the proposed<br> ;; alternative.<br> <br> (defvar sample-condition<br> =C2=A0 '(and (or buffer-file-name<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . compilation-mode)= <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . dired-mode)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . diff-mode)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . comint-mode)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . eshell-mode)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . change-log-mode))= <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "\\*.+\\*"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (not . "\\` ")))<br> <br> (benchmark-run 100<br> =C2=A0 (match-buffers sample-condition pr))<br> ;; =3D> (1.7045469830000002 20 1.1418286690000023)<br> <br> <br> (benchmark-run 1000<br> =C2=A0 (match-buffers/compiled project-buffer-conditions pr))<br> ;; =3D> (17.646938126000002 219 12.428946030999999)<br> --8<---------------cut here---------------end--------------->8---<br> <br> I guess this just goes to show that one shouldn't underestimate the cos= t<br> of a function call...<br> <br> =C2=A0 =C2=A0 LISP programmers know the value of everything and the cost of= nothing.<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0 Alan Perlis <br> </blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g= mail_signature">Jo=C3=A3o T=C3=A1vora</div> --000000000000949d9f05ec68d1db--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:22:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 09:22:47 2022 Received: from localhost ([127.0.0.1]:42947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oprE7-00023F-FH for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:22:47 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:38755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1oprE6-000231-4J for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:22:46 -0400 Received: by mail-wr1-f43.google.com with SMTP id a14so20084124wru.5 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 06:22:46 -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=UZlLeIbfM84Vqu/4QOy8bca5EZpiUlS5JQgAvA6o0vY=; b=PkE9cDRxWJrqofShsk/5A8oRxY2p6c03RMtLh+rI7NUvmTjpkDOLpaTszInKTFvXky 6u4nUVHOrD5g9QrUkCHuAMhXfqMQ9GW6F6rbkTySj15K0kaP2DkQKF2+rRYIhmbu5013 FBHkRcMpbzF1fYjqx/t6NqEIKoMVdS0WWGFpeqGL8GzEr/DBSnguikNge9N55fta0Nzc omUcVAKYQ+n0lWJyV/ngsXCMATtru3fhvTDtRXEJUyru+ZTRodj1wrqkgkK0B2qY2Wsg CYttmJEEcOcd04XbWflGAm38//8d/Y9FWmRxz6F6Lu9YOhrk+kVtz9Hhwc/oxZYXk7kP nWjA== 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=UZlLeIbfM84Vqu/4QOy8bca5EZpiUlS5JQgAvA6o0vY=; b=3uOqKqy9l5XajKXejkfpoDRi/IfIbxzxQYFXdwAIxCvWEZbJBMWnUDDEEx5VJi5OE5 tPplmAGoNBQeTK1IEzUoAa7kmIUynj/BLudJvNVaq8MRca8MmfIMSqT4dtAvuFMDtehq q34Q2ME+6BzvHAGboZpiWNsujKMKhIx3YwaKWr9DX8U661vGRscJY0u7MwQOx1dKdR0K Ta1E8X3Im3nWwOONRRdb4A0WFNgUcnglPhrmMRpz4POMbaoPIVKcktGWjzr4b04iXRty +vnQumvV1O5XeP8FEs27cXkaZIFlcs/K13mCm7bRPUCc2vf6+lhb6UUuZKzX099dGffi ulwQ== X-Gm-Message-State: ACrzQf1n93VxDB9aXzVaH/U2STNX3V9yT05EHr9/7Ghrou/ge2uIWR4m PoRSkCRq6JMWMkoWic/Rqjg= X-Google-Smtp-Source: AMsMyM5eMx/WdaIs3EkdprP6noJxp8kmoDuGk+qWtjS9fZVpN5xAImZ290zBTALXR3CfwDMVD28mrQ== X-Received: by 2002:a5d:554a:0:b0:22e:3d63:80bc with SMTP id g10-20020a5d554a000000b0022e3d6380bcmr94711wrw.30.1667308960223; Tue, 01 Nov 2022 06:22:40 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bv19-20020a0560001f1300b00236627c078esm10230408wrb.110.2022.11.01.06.22.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 06:22:39 -0700 (PDT) Message-ID: <351398ad-1292-f366-3adf-f86a129f9c90@HIDDEN> Date: Tue, 1 Nov 2022 15:22:37 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Philip Kaludercic <philipk@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN> <875yfzvawz.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <875yfzvawz.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 01:19, João Távora wrote: > We can try to make some backward compatible way, but this seems like the > perfect occasion to activate this most reasonable header in project.el: > > ;; NOTE: The project API is still experimental and can change in major, > ;; backward-incompatible ways. Everyone is encouraged to try it, and > ;; report to us any problems or use cases we hadn't anticipated, by > ;; sending an email to emacs-devel, or `M-x report-emacs-bug'. This is about the API. project-kills-buffers is not part of it. It's just a regular user-level command, to be evolved how we do with regular commands.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:03:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 09:03:53 2022
Received: from localhost ([127.0.0.1]:42934 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opqvp-0001bz-7Y
for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:03:53 -0400
Received: from mout02.posteo.de ([185.67.36.66]:39715)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <philipk@HIDDEN>) id 1opqvn-0001bi-32
for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:03:51 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 6CD3B240104
for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 14:03:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1667307825; bh=/222M8XfWI8uMFaf9WDWFktcmvGsyP2cVelny237lRU=;
h=From:To:Cc:Subject:Autocrypt:Date:From;
b=E2TirNsv46skA1FHUADAbVCehH3+GowHEc3IgecBBsBRlAgwpiVHInFf83hXdSCRU
Pdbjy0DhTf5CL9f+bWgiGKQ8CpwN7NziYbNGFaRcGhLLHVxFwfVCUcyGpwlf3b21NC
wfsKZ0spmwRZPvCAkj7Q3ywCOzQUrwLGkbD8h96KDK3ZKc9GpWgHDiR19WR2PZJVZP
O00rBnV42RW3ejUds1wwOywhQfrBSGSfVWFLU7MPIo3NVYnQwUyb7GJuRrLtg6TCqq
fwfpzaubSlij67mc+3daMkBnztBaldE4Vo0pfbEoft7B00LZQfcPPo70rvgE4AxMZF
GKmtNvGbFldkw==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4N1qvy0VtNz9rxW;
Tue, 1 Nov 2022 14:03:42 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
(=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 1 Nov 2022
11:59:12 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
<87h6zihq3q.fsf@HIDDEN>
<CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 13:03:36 +0000
Message-ID: <877d0ehlnb.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN,
58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@HIDDEN>
> wrote:
>
>
>> E.g. `display-buffer-alist' makes use of it to associate display-buffer
>> rules with buffers. Now you can add
>>
>> ((major-mode . help-mode) display-buffer-in-side-window)
>>
>> instead of trying to match being a regular expression to catch all
>> *Help* buffer names of a function along the lines of
>>
>> (lambda (buf _alist)
>> (with-current-buffer buf
>> (derived-mode-p 'help-mode)))
>>
>
> If you really want to save up on this typing, it's better to define
> a reusable helper function, or even a higher order function.
>
> (defun buffer-mode-matcher (mode)
> (lambda (b _alist)
> (with-current-buffer b (derived-mode-p 'help-mode))))
>
> You can add buffer-mode-matcher to the library if it becomes
> useful enough. Then you add:
>
> `(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window)
>
> to display-buffer-alist.
>
> But if you really want a new language your language, then I suggest
> a simple adapter buffer-matcher utility that merges the two. That way one
> doesn't couple existing utilities to the new mini-language and
> simultaneously
> the new mini-language become useful in a much wider setting for those who
> appreciate such things.
>
> (defun buffer-matcher (condition)
> "Return unary predicate of a buffer matching the CONDITION
> mini-language."
> (lambda (buf &rest _whatever) ; make it even more lax
> (buffer-match-p condition)))
>
> Later on, you might even pass an (... &optional compiled) so that the
> return value
> is syntax checked and optimized in some way at compile time.
>
> IOW, (E)Lisp already gives you the tools for these composition without
> needing to invent new languages with the drawbacks I listed.
I was curious to try this out, and implemented something along the lines
of your suggestion. The bad news is that it is at least 10 times slower
than the current implementation, that isn't even really optimised.
Perhaps I did something native and didn't see what is wrong, but here
are my notes:
--8<---------------cut here---------------start------------->8---
(defun translate-buffer-condition (condition)
"Compile a CONDITION into a predicate function."
(pcase-exhaustive condition
((or 't 'nil)
(lambda (_buffer _arg)
condition))
((pred stringp)
(lambda (buffer _arg)
(string-match-p condition (buffer-name buffer))))
((pred functionp)
(if (eq 1 (cdr (func-arity condition)))
(lambda (buffer _arg)
(funcall condition buffer))
condition))
(`(major-mode . ,mode)
(lambda (buffer _arg)
(eq
(buffer-local-value 'major-mode buffer)
mode)))
(`(derived-mode . ,mode)
(lambda (buffer _arg)
(provided-mode-derived-p
(buffer-local-value 'major-mode buffer)
mode)))
(`(not . ,cond)
(lambda (buffer arg)
(not (funcall (translate-buffer-condition cond) buffer arg))))
(`(or . ,conds)
(lambda (buffer arg)
(catch 'match
(dolist (cond conds)
(when (funcall (translate-buffer-condition cond) buffer arg)
(throw 'match t))))))
(`(and . ,conds)
(lambda (buffer arg)
(catch 'match
(dolist (cond conds t)
(when (funcall (translate-buffer-condition cond) buffer arg)
(throw 'match nil))))))))
(defvar buffer-match-p-cache (make-hash-table :test 'eq))
(defun buffer-match-p/compiled (condition buffer-or-name &optional arg)
"Return non-nil if BUFFER-OR-NAME matches CONDITION.
CONDITION is either:
- the symbol t, to always match,
- the symbol nil, which never matches,
- a regular expression, to match a buffer name,
- a predicate function that takes a buffer object and ARG as
arguments, and returns non-nil if the buffer matches,
- a cons-cell, where the car describes how to interpret the cdr.
The car can be one of the following:
* `derived-mode': the buffer matches if the buffer's major mode
is derived from the major mode in the cons-cell's cdr.
* `major-mode': the buffer matches if the buffer's major mode
is eq to the cons-cell's cdr. Prefer using `derived-mode'
instead when both can work.
* `not': the cdr is interpreted as a negation of a condition.
* `and': the cdr is a list of recursive conditions, that all have
to be met.
* `or': the cdr is a list of recursive condition, of which at
least one has to be met."
(funcall (or (gethash condition buffer-match-p-cache)
(puthash condition
(byte-compile (translate-buffer-condition condition))
buffer-match-p-cache))
(get-buffer buffer-or-name)
arg))
(defun match-buffers/compiled (condition &optional buffers arg)
"Return a list of buffers that match CONDITION.
See `buffer-match' for details on CONDITION. By default all
buffers are checked, this can be restricted by passing an
optional argument BUFFERS, set to a list of buffers to check.
ARG is passed to `buffer-match', for predicate conditions in
CONDITION."
(let (bufs)
(dolist (buf (or buffers (buffer-list)))
(when (buffer-match-p/compiled condition (get-buffer buf) arg)
(push buf bufs)))
bufs))
;; Here we will test a moderately complicated condition and time how
;; long it takes with the current implementation and with the proposed
;; alternative.
(defvar sample-condition
'(and (or buffer-file-name
(derived-mode . compilation-mode)
(derived-mode . dired-mode)
(derived-mode . diff-mode)
(derived-mode . comint-mode)
(derived-mode . eshell-mode)
(derived-mode . change-log-mode))
"\\*.+\\*"
(not . "\\` ")))
(benchmark-run 100
(match-buffers sample-condition pr))
;; =3D> (1.7045469830000002 20 1.1418286690000023)
(benchmark-run 1000
(match-buffers/compiled project-buffer-conditions pr))
;; =3D> (17.646938126000002 219 12.428946030999999)
--8<---------------cut here---------------end--------------->8---
I guess this just goes to show that one shouldn't underestimate the cost
of a function call...
LISP programmers know the value of everything and the cost of nothing.
-- Alan Perlis=20
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:58:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 07:58:22 2022
Received: from localhost ([127.0.0.1]:42888 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oppuQ-00089V-Cm
for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:58:22 -0400
Received: from mail-ot1-f53.google.com ([209.85.210.53]:45053)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1oppuO-000896-Il
for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:58:21 -0400
Received: by mail-ot1-f53.google.com with SMTP id
p8-20020a056830130800b0066bb73cf3bcso8327341otq.11
for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=JRk/8o4v6jXBCV4rY0cjToIEEdI6z+4sOOCgqpImxRc=;
b=RlMLFWS+9mFBgiK7zC+Lifko9Hny7004Daw/cv4ZaAyRTn3dPPJ7rFKu0Co95nd0/S
eESxWpirXHlXqK2ADydFCTeeAN+VzgoAML94vS+46LbeAOrRtY5+ZJTmxzr5kbuKJWxA
QFf4V2OMBc4nfxqm63lVGNCgK6VB8zV6yV2tz5K/HIbpDWqwLF21imxWqzv+2Zqjp48L
0HWpsneFzJJFJDeTACYoq4VeK2SGobHWQRXpEL28XU2kvKLtVfzH+orVOlXZ07AhGWx8
YqsbwbD2CcQ4t670vkC2CaiQb2rwEN/4Rsl15/YZa+iz/L94sc2nwrIfrQ2IvJyZQc2w
w41Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=JRk/8o4v6jXBCV4rY0cjToIEEdI6z+4sOOCgqpImxRc=;
b=foC9r3Ou58EHJi+0Lemcyu+UKUJHDITULrlPxco6ROk7eFq/tvM09Rx6UT12M4aNz0
NQGsiRxhlUr+kvwZ10ZYz2O+or+m+PvxfztH9Y5e+18ohF8iANIXMFM5ihzqkEIkf/T/
+CXHkTGf07W44j7RDPUBxZ11wGS7KdVVy4hMjbzCx5zj5f+3Fxr/7WKRIvnCYGgppSRV
WMOE8SmquirPebe8k5spdY4O4a9FZldUheVok/pCYC2x9ZijRA5CnqcAJXaFlA7/sMhb
drvf1a5V7EmpBsxHrFEsQzKi7VLuqx2mG3VSYL3z////ovFjBi39FA1V69fzWjipytF0
DHIg==
X-Gm-Message-State: ACrzQf2LU2bCgfCXaLTlEUXORo6OrWA61XFSgE+xmgS6UVEDQNia1BUa
kE+XWZPVD9C8qklkGylvyhRSpmj2vbu2XXuwf/8=
X-Google-Smtp-Source: AMsMyM5uNPF8NhlpJ+DaKOYYtPuErdoNoVl8y4yNUWaTkgPtZzLSqrP2fc99B2hqybGz+tUy4VNRzua+KqU+xKeKefc=
X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id
23-20020a9d0117000000b00666e09d577emr9504395otu.93.1667303894793; Tue, 01 Nov
2022 04:58:14 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN>
<87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
<837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
<87h6zihq3q.fsf@HIDDEN>
In-Reply-To: <87h6zihq3q.fsf@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 11:59:12 +0000
Message-ID: <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
To: Philip Kaludercic <philipk@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000061c0f005ec677090"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN,
58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--00000000000061c0f005ec677090
Content-Type: text/plain; charset="UTF-8"
On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@HIDDEN>
wrote:
> E.g. `display-buffer-alist' makes use of it to associate display-buffer
> rules with buffers. Now you can add
>
> ((major-mode . help-mode) display-buffer-in-side-window)
>
> instead of trying to match being a regular expression to catch all
> *Help* buffer names of a function along the lines of
>
> (lambda (buf _alist)
> (with-current-buffer buf
> (derived-mode-p 'help-mode)))
>
If you really want to save up on this typing, it's better to define
a reusable helper function, or even a higher order function.
(defun buffer-mode-matcher (mode)
(lambda (b _alist)
(with-current-buffer b (derived-mode-p 'help-mode))))
You can add buffer-mode-matcher to the library if it becomes
useful enough. Then you add:
`(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window)
to display-buffer-alist.
But if you really want a new language your language, then I suggest
a simple adapter buffer-matcher utility that merges the two. That way one
doesn't couple existing utilities to the new mini-language and
simultaneously
the new mini-language become useful in a much wider setting for those who
appreciate such things.
(defun buffer-matcher (condition)
"Return unary predicate of a buffer matching the CONDITION
mini-language."
(lambda (buf &rest _whatever) ; make it even more lax
(buffer-match-p condition)))
Later on, you might even pass an (... &optional compiled) so that the
return value
is syntax checked and optimized in some way at compile time.
IOW, (E)Lisp already gives you the tools for these composition without
needing to invent new languages with the drawbacks I listed.
--00000000000061c0f005ec677090
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <<a href=3D"mai=
lto:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
E.g. `display-buffer-alist' makes use of it to associate display-buffer=
<br>
rules with buffers.=C2=A0 Now you can add<br>
<br>
=C2=A0 =C2=A0 =C2=A0 ((major-mode . help-mode) display-buffer-in-side-windo=
w)<br>
<br>
instead of trying to match being a regular expression to catch all<br>
*Help* buffer names of a function along the lines of<br>
<br>
=C2=A0 =C2=A0 =C2=A0 (lambda (buf _alist)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (with-current-buffer buf<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode-p 'help-mode)))<br></b=
lockquote><div><br></div><div>If you really want to save up on this typing,=
it's better to define</div><div>a reusable helper function, or even a =
higher order function.</div><div><br></div><div>=C2=A0 (defun buffer-mode-m=
atcher (mode)</div><div>=C2=A0 =C2=A0 (lambda (b _alist) <br></div><div>
=C2=A0 =C2=A0=C2=A0=C2=A0 (with-current-buffer b (derived-mode-p 'help-=
mode))))</div><div><br></div><div>You can add buffer-mode-matcher to the li=
brary if it becomes <br></div><div>useful enough.=C2=A0 Then you add:</div>=
<div><br></div><div>=C2=A0 `(,(buffer-mode-matcher 'help-mode) display-=
buffer-in-side-window)</div><div><br></div><div>to display-buffer-alist.</d=
iv><div><br></div><div>But if you really want a new language your language,=
then I suggest</div><div>a simple adapter buffer-matcher utility that merg=
es the two.=C2=A0 That way one</div><div>doesn't couple existing utilit=
ies to the new mini-language and simultaneously</div><div>the new mini-lang=
uage become useful in a much wider setting for those who</div><div>apprecia=
te such things.</div><div><br></div><div>=C2=A0 (defun buffer-matcher (cond=
ition)</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 "Return unary predicate of a=
buffer matching the CONDITION mini-language."</div><div>=C2=A0=C2=A0=
=C2=A0 (lambda (buf &rest _whatever) ; make it even more lax</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (buffer-match-p condition)))</div><div=
><br></div><div>Later on, you might even pass an (... &optional compile=
d) so that the return value</div><div>is syntax checked and optimized in so=
me way at compile time.<br></div><div><br></div><div>IOW, (E)Lisp already g=
ives you the tools for these composition without <br></div><div>needing to =
invent new languages with the drawbacks I listed.<br></div></div><br></div>
--00000000000061c0f005ec677090--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:38:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 07:38:30 2022 Received: from localhost ([127.0.0.1]:42870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oppbC-0007JF-6I for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:38:30 -0400 Received: from mail-ot1-f43.google.com ([209.85.210.43]:43732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oppbA-0007Iw-6Y for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:38:28 -0400 Received: by mail-ot1-f43.google.com with SMTP id k59-20020a9d19c1000000b0066c45cdfca5so3889329otk.10 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jOLjSHgH0pH7J8bvpsykwETDk/uvXbPgL6h5D0rdFgo=; b=e78S+biNk/o7TcrUGUT8Mouc/jwttHgiqtBjpjYRrnxSJNB00V0lL18+Zfm+k/jppq HU9sy6U+SAkxJRqbPHS6Hxch4wQagj5R0E2hplCX1nQEXnIDw/PTSL5c7hS+TiU8DTHM yGyU4S073l/lfkKngnGlrfqiMLmWVPCQuM/na3i8g4zp/4WRRLdXk/mTcUm7YGQQe7zi 9DZo0pt8uvuXyRD9ZaN5cMJu+R2/RppZd44vsGr6tzAz/jJHA409w3UmgiKSmEYlFP/u b9qoihZYAcjdB04rEz2z0ictg1EJwQySi6VOrxh4czhvEOKtpPYA0X/MUa5QekJNqmjf ba+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jOLjSHgH0pH7J8bvpsykwETDk/uvXbPgL6h5D0rdFgo=; b=hK71gfvGuUYrmewe3f+c9FczNa7upB1wtx4wbrmkvkM77YhVvO5ueQiPGss+/1/CN5 1aSYJ/FAFsNNccG6RzccPBWzVvkjl4KtBtvFErWLhMLjVV93I0UvWVU6FxVLzWgZ1VbB +i+DXyBrE0H8dMCeScQOOwpF9Gk2VB9Pq3U0ewRemuoU66aI3CnEt+TfvmeMqIita/hj rLIcXDSvas/Q8cuELs91kA2oDoi07yVrAjGuCPKYEVt+Rqr6g1dFzKOxTXX4q1F7PGx/ gM0RMKDPvSEf/WhKHqC1dKSBCh4MCHSHX24Y1JY30fgOKu2XXhDF2htSBRTDx4YJK4Jp CT8g== X-Gm-Message-State: ACrzQf11NPWwKdRjqFkobs82X3+xKhripl22ytIbl7K/tZooSYofTrx2 d6u2geM3fN8dgqTLPond9JzwCH8I84qjCnrgB8Q= X-Google-Smtp-Source: AMsMyM7n2DeUAfBHaHjXxtSCAU28NQ9rJSD2H4h3Fbk4KvwgFnBJitnbjh7WS26bMm/3c0TXSDRFjQJ36rmIAXJ69L0= X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id 23-20020a9d0117000000b00666e09d577emr9457953otu.93.1667302701625; Tue, 01 Nov 2022 04:38:21 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> In-Reply-To: <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 11:39:20 +0000 Message-ID: <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000004374ad05ec67296c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000004374ad05ec67296c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022 at 11:23 AM Dmitry Gutov <dgutov@HIDDEN> wrote: > On 01.11.2022 12:59, Jo=C3=A3o T=C3=A1vora wrote: > > For me, it looks like match-buffers is reinventing > > cl-remove-if-not and match-buffer-p is reinventing ... unary predicate > > function of a buffer? > > And Eglot is reinventing url-http. > Really? Where? I don't understand how, might it might very well be. Can suggest an improvement? I love to kill code, so let 'er rip. Jo=C3=A3o --0000000000004374ad05ec67296c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Tue, Nov 1, 2022 at 11:23 AM Dmitry Gutov <<a href=3D"mailto:d= gutov@HIDDEN">dgutov@HIDDEN</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">On 01.11.2022 12:59, Jo=C3=A3o T=C3=A1vora= wrote:<br> > For me, it looks like match-buffers is reinventing<br> > cl-remove-if-not and match-buffer-p is reinventing ... unary predicate= <br> > function of a buffer?<br> <br> And Eglot is reinventing url-http.<br></blockquote><div><br></div><div>Real= ly? Where? I don't understand how, might it might very well be.<br></di= v><div>Can suggest an improvement? I love to kill code, so let 'er rip.= </div><div><br></div><div>Jo=C3=A3o</div></div></div> --0000000000004374ad05ec67296c--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:35:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 07:35:11 2022 Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oppXz-0007DT-Ar for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:35:11 -0400 Received: from mail-oa1-f51.google.com ([209.85.160.51]:39620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oppXx-0007D8-3R for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:35:10 -0400 Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-13c569e5ff5so16063927fac.6 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ySz54CLs/75+7kqT7Vdy0f4+HMq5N3vdhin5y98k0sw=; b=aBaZWynci95xK6wzq/dsn0sBTtOHfsfR8+ByFrHS0M9W/MKHPdMHftyct5f3BGKTqM dd4InUo4TtOw3NmF6HyLoagw7XDw2NgKYXfV3eN09briJz+wFAeyJMsi5/KglOA88V9I AdPHeEHIMF5I2DDvyVoZ6QnFyx6e3h5cUx2UlDm1qfMALlnwPP6u0Ms/ZjHT420v5sQs r32o2OwOyJs3GuhzNNyFBBE/iIpKKxFgKLIynn3Vu+qaanIyzm1BsnAZdX6v0KgCmf1E 2ek3wXtWx/xBCZeK14Ek9BkZ53FS/L+csP4jfmAOzioexGQqQF9V1XVkI8gOlmcyp072 /+SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ySz54CLs/75+7kqT7Vdy0f4+HMq5N3vdhin5y98k0sw=; b=WzExmbK9SAxnoOhsCmAIgvVjseDh9A/ANEU7ZKKTlfYkviiP+b6cO2giPDLhfB5A1t ZH+wBLgOLYzKeNp8hvAUqQItd6/aF4z8lhwHK/0VGCsm09CVglghDNpMzEKW50sBRhJH x9B7v2giPnspPV9h6ASushx+hlcXGxKoCyt8M16PNPZwe+0GEA7Nwhqfm4oVcCLAtoqt BuYp8uMbQMQ0q8G2oeuQRrJXdVLNnB0t16q9iqIQFmfWIQbB0iJ8W5KVfmXKf2RsCVK8 HOdIlyG8jtOOlYPLIO8TUczz++kuUUPXWphwyw1kp8Q4itlHRF90g519cLdiil0ykpfe lgng== X-Gm-Message-State: ACrzQf2hsQTLDW0QY5dmAklpYO6ZcQYgGhhQd+wFQ/pUqaUYxmeaykCn Uzgn0sx9gav17+g/GOcBxpN0MRVPjN5LKXFinR0= X-Google-Smtp-Source: AMsMyM7uL4L0WNBNya/dP+QD/PJDfAcZVaU570ONXmfKqEgCZgEGlg2APwbAr8LGW3bO++6hQbBD/4Yo90eQSy/4YDU= X-Received: by 2002:a05:6870:e242:b0:13b:d561:ad02 with SMTP id d2-20020a056870e24200b0013bd561ad02mr10936686oac.215.1667302503461; Tue, 01 Nov 2022 04:35:03 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> In-Reply-To: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 11:36:02 +0000 Message-ID: <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000073b88c05ec671d8e" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000073b88c05ec671d8e Content-Type: text/plain; charset="UTF-8" On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <dgutov@HIDDEN> wrote: > I suggest you try it first. It works in my test > Disaster, really? The reason I came about the Gnus problem was when using it to reply to some emails here and trying out the C-x p k and finding out all my Gnus buffers were gone. > Do you know whether CIDER will be satisfied by the same patch I sent > previously? No. I don't use it. You should ask Manuel, who reported this in the original discussion. > >>> 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. It's Philip's bug report. I don't use C-x p k, in fact I learned about it here. It's then I started trying it, because in principle it is very useful, that I found out how broken it is for many other situations: ibuffer, *gnus*, and it's a shame we can't use 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. You are attributing ill-intent to me from a moral high-ground you can't really claim. I had no idea as to the authorship, so I can't have been engaging in those perfidious tactics. But do I apologize for the word "abomination". If it helps I'll show you round to plenty such things written by myself in the past. I've explained to Philip objective reasons why I think evaluated mini-languages are almost always inferior to a decent Lisp such as Elisp. You could perfectly reasonably deprecate these two variables. > They can, though, even if odds are low. It can also happen through some > other automation, which Emacs lets the users do freely. That automation is just as buggy as C-x p k, and should be fixed, but the only such automation we know is C-x p k. > 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. Not to mention it's just [insert acceptably derogatory word here] to protect implementation details from misbehaving code that is under our control and can just be fixed. --00000000000073b88c05ec671d8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <<a href= =3D"mailto:dgutov@HIDDEN">dgutov@HIDDEN</a>> wrote:<br><br>> I = suggest you try it first.<br><br>It works in my test<br><br>> Disaster, = really?<br><br>The reason I came about the Gnus problem was when using it<b= r><div>to reply to some emails here and trying out the C-x p k and finding = out <br></div><div>all my Gnus buffers were gone.=C2=A0 <br></div><div><br>= </div>> Do you know whether CIDER will be satisfied by the same patch I = sent<br>> previously?<br><br><div>No.=C2=A0 I don't use it. You shou= ld ask Manuel, who reported this in <br></div><div>the original discussion.= <br></div>=C2=A0<br>> >>> you're making a gun that only bac= kfires 5% of the time.<br>> >> Yours is the first instance so far.= <br>> > We seem to use different algebraic systems.<br>> This is l= iterally the first bug report on the subject.<br><div><br></div><div></div>= It's Philip's bug report.=C2=A0 I don't use C-x p k, in fact I = learned about it<br>here.=C2=A0 It's then I started trying it, because = in principle it is very useful,<br><div>that I found out how broken it is f= or many other situations: ibuffer, *gnus*, <br></div><div>and it's a sh= ame we can't use it.</div>=C2=A0<br>> what you are doing is pressuri= ng all other participants into your POV by<br>> means of an insult. That= usually works better if the offending code was<br>> written by somebody= who already left (the project/the discussion/the<br>> company/etc), or = is a little younger.<br><br><div>You are attributing ill-intent to me from = a moral high-ground you can't really <br></div><div>claim.=C2=A0 I had = no idea as to the authorship, so I can't have been engaging in those <b= r></div><div>perfidious tactics.=C2=A0 But do I apologize for the word &quo= t;abomination". If it helps</div><div>I'll show you round to plent= y such things written by myself in the past.<br></div><div><br></div><div>I= 've explained to Philip objective reasons why I think evaluated</div><d= iv>mini-languages are almost always inferior to a decent Lisp such as Elisp= .</div><div>You could perfectly reasonably deprecate these two variables.<b= r></div><br>> They can, though, even if odds are low. It can also happen= through some<br>> other automation, which Emacs lets the users do freel= y.<br><br>That automation is just as buggy as C-x p k, and should be fixed,= but<br>the only such automation we know is C-x p k.<br><br>> I'm fa= irly sure that the solution I offered would be easy enough <br>> impleme= nt, to actually protect the vulnerable buffer.<br>> I suppose we are not= doing that, however.<br><br><div>You sketched an untested code-less idea a= nd I explained how flawed it was. <br></div><div>Not to mention it's ju= st [insert acceptably derogatory word here] to protect</div><div>implementa= tion details from misbehaving code that is under our control <br></div><div= >and can just be fixed.<br></div></div> --00000000000073b88c05ec671d8e--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:27:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 07:27:32 2022
Received: from localhost ([127.0.0.1]:42862 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oppQa-0004mg-8e
for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:27:32 -0400
Received: from mout01.posteo.de ([185.67.36.65]:42545)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <philipk@HIDDEN>) id 1oppQY-0004mP-8O
for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:27:31 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 7F33B240026
for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 12:27:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1667302044; bh=HL9xnZhzIT055WSzsrYrsZTjAKiUULttndU5fbMF5Rs=;
h=From:To:Cc:Subject:Autocrypt:Date:From;
b=qlU61K/fextzQMqdFnoZzIOhfGe4ZbCEEAXq5Z5hiEKftn3TTCeADoT7T+R1GwavW
S9+flxUE1aWLph3QPfJ+tj4BCdHP0Pl35+Phj3aikQKLGnbZdneVBH9a/0yq1WdpjO
EmdLdX5Fw9G4HIxKrjwQXjHj9fD1fMsJu29o5Ic+aWintVRILlYxpIkm6l9pqO5Jt2
cAXlSoZn70mD8dtoXFiO0hxc/3zp/rE8WJ/g2cf2uQkvXYf4uSnr11ZqWLdaoojZQV
3OqZkRoCLVspw+UVk1rMbmSqDoxNqVmyfpAuG5NUY5cE/qVJ6lSxmB61BVjGCztt9Q
jazZv9c3jPlNQ==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4N1nmp1w35z6tpn;
Tue, 1 Nov 2022 12:27:22 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
(=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 1 Nov 2022
10:59:41 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
<87edunvhf2.fsf@HIDDEN>
<6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
<87tu3jgdbv.fsf@HIDDEN>
<CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 11:27:21 +0000
Message-ID: <87h6zihq3q.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN,
58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <philipk@HIDDEN>
> wrote:
>
>>
>> BTW, if there are major objections to the language, I should point out
>> that the new `buffer-match-p' in Emacs 29 uses the same language and has
>> already found usage in a number of spots in core Emacs. There would
>> still be time to address any issues you might have, and avoid a
>> long-term mistake.
>>
>
> For me, it looks like match-buffers is reinventing
> cl-remove-if-not and match-buffer-p is reinventing ... unary predicate
> function of a buffer?
You could say that, though I would argue it is an easier way to express
common predicates, while not making anything else more complicated.
E.g. `display-buffer-alist' makes use of it to associate display-buffer
rules with buffers. Now you can add
((major-mode . help-mode) display-buffer-in-side-window)
instead of trying to match being a regular expression to catch all
*Help* buffer names of a function along the lines of
(lambda (buf _alist)
(with-current-buffer buf
(derived-mode-p 'help-mode)))
> I'm not fond of these mini-languages because they're less expressive, they
> end up being only minimally less complicated and bug-prone, they can't
> automatically be byte-compiled for efficiency, and they can't automatical=
ly
> be byte-compiled for correctness/diagnostics. If one makes a mistake,
> the backtrace is much more complicated.
I agree in principle, but this should be alleviated by using a lambda
function as a predicate. The above check still works and can be used
anywhere you would use `buffer-match-p'.
> So these mini-languages may make sense to define filters in thunderbird or
> something, but throwing Elisp away here generally doesn't make sense to m=
e.
>
> But there may be exceptions (although this project.el one doesn't seem one
> of them) so why don't you show examples of use of these new helpers and
> so we can compare side by side with the Elisp-only alternative.
I am biased, but I believe that the language could even find more use in
project.el, by having `project-buffers' just call `match-buffers' with a
special `buffer-match-p' predicate. Here is a sketch of how that could
look like (I haven't tested it yet):
--=-=-=
Content-Type: text/plain
Content-Disposition: inline
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..b55c245368 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -352,15 +352,28 @@ project--remote-file-names
(concat remote-id file))
local-files))))
+(defun project-includes-buffer-p (buffer dir)
+ "Return non-nil if the `default-directory' of BUFFER is below DIR."
+ (file-in-directory-p
+ (buffer-local-value 'default-directory buffer)
+ dir))
+
+(defcustom project-buffer-conditions
+ '(and (or buffer-file-name
+ (derived-mode . compilation-mode)
+ (derived-mode . dired-mode)
+ (derived-mode . diff-mode)
+ (derived-mode . comint-mode)
+ (derived-mode . eshell-mode)
+ (derived-mode . change-log-mode))
+ project-includes-buffer-p)
+ "A buffer predicate for matching what buffers belong to a project."
+ :type 'buffer-predicate)
+
(cl-defgeneric project-buffers (project)
"Return the list of all live buffers that belong to PROJECT."
- (let ((root (expand-file-name (file-name-as-directory (project-root project))))
- bufs)
- (dolist (buf (buffer-list))
- (when (string-prefix-p root (expand-file-name
- (buffer-local-value 'default-directory buf)))
- (push buf bufs)))
- (nreverse bufs)))
+ (let ((root (expand-file-name (file-name-as-directory (project-root project)))))
+ (match-buffers project-buffer-conditions nil root)))
(defgroup project-vc nil
"Project implementation based on the VC package."
@@ -679,7 +692,7 @@ project-buffers
(project--git-submodules))))
dd
bufs)
- (dolist (buf (buffer-list))
+ (dolist (buf (cl-call-next-method))
(setq dd (expand-file-name (buffer-local-value 'default-directory buf)))
(when (and (string-prefix-p root dd)
(not (cl-find-if (lambda (module) (string-prefix-p module dd))
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
DQo+IEpvw6NvDQo=
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:23:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 07:23:45 2022 Received: from localhost ([127.0.0.1]:42857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oppMv-0004fm-MC for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:23:45 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:37623) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1oppMt-0004fW-TZ for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:23:44 -0400 Received: by mail-wm1-f42.google.com with SMTP id ay14-20020a05600c1e0e00b003cf6ab34b61so3212047wmb.2 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:23:43 -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=lG60s7Pd9RolxnP2DFBavjgUhldYVcDGqzI6EPhi0bQ=; b=bzRrRQWiK1E+Cyodaf+Ul1v6tDlTkTzp7eSxMMEqT6cntF/qxLPPPZxXzTwq5YNdiQ bp8WK3fwGT8yJjNdb0tGlBeUAQsL09cQYoZiifhf9p+g1J510Y/1AO1s2MI5rK6oKgH5 cMZaYQnnky5lpKhS4gBlgFGG1RV+aLJXour+VFqnBqvgseI8AeIeFfxHuks/HKMDTBOn ZjbL1h4s4YhG4l97FAkStIPGTZ1Q7ZSldk30TcG0T5O8AYkqKgqywBwOOCdAkCKAKMqV rBkVdGB6rYlm/2g/ZgYNzvhGwD4ZfNs6z1EL46i0kPQk9Y4U4F0jR0vQR4z0GKlch5mn H+jA== 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=lG60s7Pd9RolxnP2DFBavjgUhldYVcDGqzI6EPhi0bQ=; b=IlAkwg7W6xL1XVVdYYdxIwdZ6pz7H6ezV7fbe+WktI91JH3VVMeHDCBTAjJvdvKMvb bYbXLqqnkyrYCBdpV2GTs3xyiOyaUzLhNipKFB+dtZ9nWoM1xpZjAeiXdDc8DM+fXlSZ wj5+sLzjyOAM6yyTsnskFKlelIibiN7qtvrpw0Fw0bn1fLApIlhISx+lQ563abUOSWXW Yy3Au3mpfseH5cjoiyPhwF8NtZw/mZTonPEXLS5eyuytJp4rcvtrJ7vpnb1fwn8e8Nj2 gHPaLj8MLxLH42RFN9eJXoJtjR+8WW+A4kXGFkaoKV5F2Tgqzzse+pCWdoRnIfMbj7ZZ uQxw== X-Gm-Message-State: ACrzQf3Cdu4jiN6inghBjG8uqFQkRmVNDatboBC8vDY3dr+U2SUDqnyU u2Vdve12jbX1QoRi8/xpy7Y= X-Google-Smtp-Source: AMsMyM7WKNeJn0GYlUgyRDiY3eNuLvTvJ7t/1b+MxTzb6yVL9kASoSR3D/jIsffWRhWEj/94IOVI3g== X-Received: by 2002:a05:600c:2314:b0:3cf:6b2a:7d93 with SMTP id 20-20020a05600c231400b003cf6b2a7d93mr8491991wmo.33.1667301817855; Tue, 01 Nov 2022 04:23:37 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m23-20020a05600c3b1700b003b4ff30e566sm1474348wms.3.2022.11.01.04.23.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 04:23:37 -0700 (PDT) Message-ID: <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN> Date: Tue, 1 Nov 2022 13:23:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>, Philip Kaludercic <philipk@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 01.11.2022 12:59, João Távora wrote: > For me, it looks like match-buffers is reinventing > cl-remove-if-not and match-buffer-p is reinventing ... unary predicate > function of a buffer? And Eglot is reinventing url-http.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:58:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 06:58:50 2022 Received: from localhost ([127.0.0.1]:42843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opoyo-0003wZ-1r for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:58:50 -0400 Received: from mail-ot1-f52.google.com ([209.85.210.52]:44863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1opoym-0003wL-Cv for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:58:48 -0400 Received: by mail-ot1-f52.google.com with SMTP id p8-20020a056830130800b0066bb73cf3bcso8253466otq.11 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 03:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Jqw/+wWtuUFY0a7+SPLJy5pwOWdg+HbRhUJaqXs86sk=; b=D/c62oRULiQ40SHUYHKMDzziFNQkGRmJumtN0f4DmYePGxOS5EbdgZgPl3iFCvx1Wt ScXyAfgHybMNdHwtXUFccvS7NOJt/UwtCz3Ekc0BPvxjiRFiB0hmSLOruYkFUATnKHFU q5uMxgSN+O3kBqthrVIbpiWTBGpJBmXZDc90MWftJTrrQv1Dnh2+lyTdCAqlnnGaWXVq 61X92E8NW+ifKDioXz5WLsFhrYwoyccT0KlMx8mADQOA1WcIckGGPRTSxCD3ZOxfb6tS 3xcUMg11HtC0HGLYiTLZGhQ2YEA1FxnHPZyTLAJXbt4+Z0PIHSfPhlOAujn7amWCZeVM s1WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Jqw/+wWtuUFY0a7+SPLJy5pwOWdg+HbRhUJaqXs86sk=; b=N+8QKRmLPDOKigaVaRCzu/d8UWMJF29I0rIDE2thB31qKGGYysbRjn/k2bPYfYMr9k emzmXJ5uUjFTIHEVw0xEFMEDa2qasUIfMEp+6d+DptUkm7mpyYScBd8mFZ9sCQn+FtS/ KE3pA7nLKdRCiSQCRRx/dC49c6p08Kruiqafr4gfwgVFbcuIUg8oyn8Z5JTCneWDcEKl NyodaMUEtEPaeitYht7GmslicLkp0pEHM5UkEYR8Ifsqchvo3m28xvDkdEAivonZMlvd jn80r0pqAYMd3in0jPP61Q6AWeAAsN05angFTT/5dPP3QU69ufKKi5QLAd93Y2PTVWOA foDA== X-Gm-Message-State: ACrzQf3eFxnv/WFQ8/Yag625L+QAfqXmqboQrCUWaULg2F58uwOiD845 RJwwhndi2gSSF1MFzpe+m7FhyqqEUAwNctlhkpM= X-Google-Smtp-Source: AMsMyM7XUrlegFYeeAlyZVYSXH/m65c5G9vCKDI8KpTqLgd9RjBeS06xxcONHKxPtJCyB7j5LegxjCNDSyhitiQ03OQ= X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id 23-20020a9d0117000000b00666e09d577emr9366168otu.93.1667300322666; Tue, 01 Nov 2022 03:58:42 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN> In-Reply-To: <87tu3jgdbv.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Tue, 1 Nov 2022 10:59:41 +0000 Message-ID: <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000776cca05ec669ba7" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000776cca05ec669ba7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <philipk@HIDDEN> wrote: > > BTW, if there are major objections to the language, I should point out > that the new `buffer-match-p' in Emacs 29 uses the same language and has > already found usage in a number of spots in core Emacs. There would > still be time to address any issues you might have, and avoid a > long-term mistake. > For me, it looks like match-buffers is reinventing cl-remove-if-not and match-buffer-p is reinventing ... unary predicate function of a buffer? I'm not fond of these mini-languages because they're less expressive, they end up being only minimally less complicated and bug-prone, they can't automatically be byte-compiled for efficiency, and they can't automatically be byte-compiled for correctness/diagnostics. If one makes a mistake, the backtrace is much more complicated. So these mini-languages may make sense to define filters in thunderbird or something, but throwing Elisp away here generally doesn't make sense to me. But there may be exceptions (although this project.el one doesn't seem one of them) so why don't you show examples of use of these new helpers and so we can compare side by side with the Elisp-only alternative. Jo=C3=A3o --000000000000776cca05ec669ba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <<a href=3D"mai= lto:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"><br> BTW, if there are major objections to the language, I should point out<br> that the new `buffer-match-p' in Emacs 29 uses the same language and ha= s<br> already found usage in a number of spots in core Emacs.=C2=A0 There would<b= r> still be time to address any issues you might have, and avoid a<br> long-term mistake.<br> </blockquote></div><div><br></div><div>For me, it looks like match-buffers = is reinventing<br></div><div>cl-remove-if-not and match-buffer-p is reinven= ting ... unary predicate <br></div><div>function of a buffer?<br></div><div= ><br></div><div>I'm not fond of these mini-languages because they'r= e less expressive, they</div><div>end up being only minimally less complica= ted and bug-prone, they can't</div><div>automatically be byte-compiled = for efficiency, and they can't automatically</div><div>be byte-compiled= for correctness/diagnostics.=C2=A0 If one makes a mistake, <br></div><div>= the backtrace is much more complicated.</div><div><br></div><div>So these m= ini-languages may make sense to define filters in thunderbird or</div><div>= something, but throwing Elisp away here generally doesn't make sense to= me.</div><div><br></div><div>But there may be exceptions (although this pr= oject.el one doesn't seem one <br></div><div>of them) so why don't = you show examples of use of these new helpers and <br></div><div>so we can = compare side by side with the Elisp-only alternative.</div><div><br></div><= div>Jo=C3=A3o<br></div></div> --000000000000776cca05ec669ba7--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:52:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 06:52:02 2022 Received: from localhost ([127.0.0.1]:42834 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oposD-0003kS-Pz for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:52:02 -0400 Received: from mout02.posteo.de ([185.67.36.66]:42379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oposB-0003kD-Ua for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:52:00 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6974D240101 for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 11:51:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667299914; bh=9W3kVx4UOPrL/fc5FYsR1UnBHRmZAEbt1vGqOqT6AJw=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=dJtPvcqxYkBEG50a/TNBp0zr18t9lYxjg0Y4K1VeuI+8pF2YnRhVyh3eC6NO6sgFg pSdEogL1rxJp/XfhZikwBPyQDDOgrnpVCKoCx4U593EZr7YKR4n6OjRaZHHNx9lWdh GwzXrcXp750R8RYMvToYBqfhNrOps/Aiz72907dx7UyQb3Ry/nCDaTUZaIG7aNJZxq KH1+Ql2PkHnlxq9KG7ocPMfc1YB0SomBSIYpEVq5KJ92e5Yqvp0wSJ1GgeDVD+liXF +UjYXVNHJg1FriugOfqI/oqO9N8BB25lodzLQVVw0kAr5g4Jq2tp6TgXSQi+Rb8jfn C48F9ENaCFv5Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1mzs5R4rz9rxF; Tue, 1 Nov 2022 11:51:53 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <875yfzvawz.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Mon, 31 Oct 2022 23:19:24 +0000") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN> <875yfzvawz.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Tue, 01 Nov 2022 10:51:53 +0000 Message-ID: <87pme7gd6e.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > In practice, I doubt many people are setting these variables. A GitHub > code search, where it is normally easy to find customizations of > variables since users version their configurations there, turns up 0 > results for customizations of project-ignore-buffer-conditions and not > more than a handful for project-kill-buffer-conditions, for example. In > contrast you can see hundreds of people setting things like > eglot-autoshutdown or ibuffer-filter-groups (and settings of > scroll-bar-mode are in the thousands). So I'd say the risk is minimal > and the benefit considerable. If people are customising the variable everything is fine, the issue I was thinking about were those who are relying on the default behaviour that might change without them expecting it to.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:48:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 01 06:48:48 2022 Received: from localhost ([127.0.0.1]:42830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opop6-0003e5-69 for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:48:48 -0400 Received: from mout02.posteo.de ([185.67.36.66]:56209) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1opop4-0003dn-5T for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:48:46 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 9F87D240108 for <58839 <at> debbugs.gnu.org>; Tue, 1 Nov 2022 11:48:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667299720; bh=C2l4nFq11iu9wU5lcwQLKk2+PLCKj2RaNHvGdbebmtU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=nO37SwuqqzsK61uk1C0g1y8TSoeQ2Y/AuwXvE1qxk8mN9rggvlKzfirpX48hQcTte gl308k3kVcGv0LZqbQkSckbeb89uDEArU5MXy+2TTyIAcAo1pQyAIWzXkPeY4++QKQ pzJgrTELKFlj2x0bZdQpXpn2C1gtMu7o/znvE7ikRAeAsBXN4cmyZ3Q+EV0z82WX8h 08jSTTftJmNh9SHp2eGk3Ez57T2d+4Z47Lvb+YfqhI1EsCarzvc7LptFCb1KZR1rwZ u5sPl+AMgE3LS3D+Qct4VuK0tIDDNw1+Y7YYj04ZazlOIW1+zeQAEYLhgmk8qwykT6 eGL3A8fw917/g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1mw45nX4z9rxV; Tue, 1 Nov 2022 11:48:36 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> (Dmitry Gutov's message of "Tue, 1 Nov 2022 00:51:53 +0200") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Tue, 01 Nov 2022 10:48:36 +0000 Message-ID: <87tu3jgdbv.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: >>>> 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. I believe that was me... BTW, if there are major objections to the language, I should point out that the new `buffer-match-p' in Emacs 29 uses the same language and has already found usage in a number of spots in core Emacs. There would still be time to address any issues you might have, and avoid a long-term mistake.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 23:18:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 19:18:23 2022
Received: from localhost ([127.0.0.1]:42236 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ope2w-0005hA-Qo
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 19:18:23 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:39510)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1ope2u-0005gv-UV
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 19:18:21 -0400
Received: by mail-wr1-f53.google.com with SMTP id o4so18045510wrq.6
for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 16:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding: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=Ah3ZhypLZ18loyzr9hJvDM6P63xasxK8+Pz9+ZVhwYU=;
b=UQKrHiDSAg9LYyN+icLL+0EGUoI5DcKIhJqmO6FZYfmtxJr72TvVCmdnS5RjADDNXM
A+D/yhzVLB6NujbPUlSq80LQ4fHI8g0NNQLS0s8BO6nq2jEVJilczUjV+Larx+F3wxMk
T8J9WyJ+NsK2B9/3vixAlRglKCBJIAIDrQtsVJhQQ4Ex2TqaChr8evS4P+wqLJHRYyhP
eYuzqH7MrDV5TPR44NF3L70rqFzMtLK+2FhIeTOdO6zJTAnyYIyWx0RmCVdNKYx4mQuc
0afHpO1rD2+HDhPXV6k3YY43hZnPe7wBA7PdoFx6qtnbhJql+jv+QLrdcAf8r+BiyS6H
vNug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding: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=Ah3ZhypLZ18loyzr9hJvDM6P63xasxK8+Pz9+ZVhwYU=;
b=d6RDpe6luWmsWScpgKAX2EVzpln7mj75zRpvYp4a5XY1Wl6/+Pm5rRRZ0P2VaFwCXb
j72lAG3QoWag7/vu/Y2U+u3RqA3bY40hMnGCgzCWxAPCULVVq8n8v/Q3/mDbS/x+sPmW
p3Vr56FqY4637v5ZPWFDHmFjSEQ/AGERfnkpiDqH2LyTJOlAcd+EA45GEj2dNVH48Y6f
xhwTY/Z6yZrkP/k36Id4gb8XoGagki+fgZa86pw6RUuORG3vm8D5imfYY/6mIWFmhTab
PlCU/SpQs/odfDvt6vnlED87AnkawV72X2l2suhzAqNiqkn7fEhnRTcNueQHnGelWQNq
qFrg==
X-Gm-Message-State: ACrzQf0hZLWK/9Ae9gfcbTvnZlSYrZIZ2O2E6gjvyY9v8dcD6dZJOEDH
SsOxI6phsD3CGxxnSprsNdE=
X-Google-Smtp-Source: AMsMyM41gWNRPSPjm2YzVwUl5d4b0XjZzIMLWIyUiNGmCGUZvfn7rGzCc9OVNnY93Sm7LByuEmy8Ig==
X-Received: by 2002:a5d:4351:0:b0:236:c820:97b8 with SMTP id
u17-20020a5d4351000000b00236c82097b8mr5665053wrr.699.1667258294884;
Mon, 31 Oct 2022 16:18:14 -0700 (PDT)
Received: from krug (87-196-74-163.net.novis.pt. [87.196.74.163])
by smtp.gmail.com with ESMTPSA id
k5-20020a05600c0b4500b003c6c4639ac6sm8518661wmr.34.2022.10.31.16.18.13
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 31 Oct 2022 16:18:14 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <87k04ggixk.fsf@HIDDEN> (Philip Kaludercic's message of "Mon,
31 Oct 2022 14:35:19 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN>
Date: Mon, 31 Oct 2022 23:19:24 +0000
Message-ID: <875yfzvawz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Philip Kaludercic writes: > João Távora writes: > What existing
hooks?
Content analysis details: (3.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.53 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.221.53 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN,
58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Philip Kaludercic writes: > João Távora writes: > What existing
hooks?
Content analysis details: (2.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.53 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.221.53 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Philip Kaludercic <philipk@HIDDEN> writes:
> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> What existing hooks?
The major-mode hooks, naturally.
Using major-mode hooks and buffer-local variables is the standard Emacs
way of attaching characteristics to buffers. The Elisp required is
trivial and there are thousands of examples for doing it out there.
There's no need to introduce new less powerful and more awkward
languages in variables.
>> It's quite clear that _some_ non-file-visiting buffers can be considered
>> as belonging to a project's working set. But it's very very easy to
>> come up with many that cannot be considered so.
>
> I have to admit that I am more and more inclined to make the list a
> opt-in thing, where we explicitly mark those major modes that are tied
> to a project.
Yes, and we can always later overhaul project-owned to be function for
doing more complex calculations based on the name of the buffer, for
example. But a simple boolean would probably suffice for vc buffers,
and other earmuffed buffers created by packages in Emacs.
>> To name one. The above is just the converse of the solution proposed by
>> Philip before.
>
> I would be fine with this in principle, my only worry is backwards
> compatibility for those who use project.el from ELPA.
We can try to make some backward compatible way, but this seems like the
perfect occasion to activate this most reasonable header in project.el:
;; NOTE: The project API is still experimental and can change in major,
;; backward-incompatible ways. Everyone is encouraged to try it, and
;; report to us any problems or use cases we hadn't anticipated, by
;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
It sure seems like there were things that project.el's authors didn't
anticipate. A mistake is a mistake there should be no shame in
rectifying it.
In practice, I doubt many people are setting these variables. A GitHub
code search, where it is normally easy to find customizations of
variables since users version their configurations there, turns up 0
results for customizations of project-ignore-buffer-conditions and not
more than a handful for project-kill-buffer-conditions, for example. In
contrast you can see hundreds of people setting things like
eglot-autoshutdown or ibuffer-filter-groups (and settings of
scroll-bar-mode are in the thousands). So I'd say the risk is minimal
and the benefit considerable.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:52:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 18:52:04 2022 Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opddU-0004zS-BT for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:52:04 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:44957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opddS-0004yx-6q for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:52:02 -0400 Received: by mail-wm1-f50.google.com with SMTP id bg9-20020a05600c3c8900b003bf249616b0so8939470wmb.3 for <58839 <at> 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) 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) Message-ID: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> Date: Tue, 1 Nov 2022 00:51:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87edunvhf2.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 31.10.2022 22:58, João Távora wrote: > Dmitry Gutov <dgutov@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:50:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 18:50:58 2022
Received: from localhost ([127.0.0.1]:42204 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opdcP-0004x1-Pn
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:50:58 -0400
Received: from mail-wr1-f52.google.com ([209.85.221.52]:36406)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1opdcO-0004wo-Mh
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:50:57 -0400
Received: by mail-wr1-f52.google.com with SMTP id j15so17989083wrq.3
for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding: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=HfDjTwcYtq2bAiely7jwUrRiOLW3bm8lz0i+fgxZiDw=;
b=MbQ8j4+UL3RYx/7vApv/pOb0CASx0/1t4S5tfhx1yh/P3LssVjvlfImPcrXuQqH4bz
XiNR4zoNhbAm9j5A28F5C1WMHHd+j8ifk6sR27N3wX9AiU82FQRGQEUBIaQwhp1DLSAm
5kYzlmqMNfzb+QrqZFuUmBC2STqEZvD1Q92C+cV4HJGb6g85otE4VDoIjoYp0GNHNVIF
oYtqVH5uckhITx53qQ0c9yMAfK4diy3bw8QahaYK/kzWDq7Xb4ScBRwvkaNyUzSnXXPO
8wXWQTmbakQHUDaj0SYQXOXYPLyhotPr8ReR8R6lSzOVoMxWSNWEL9R2bzi5/JlPlfDP
7GCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding: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=HfDjTwcYtq2bAiely7jwUrRiOLW3bm8lz0i+fgxZiDw=;
b=UD3eJTCl81Azm7U8NEVXOx2BFh+rqvJA/5KKuShKhT1NWfnuwVikJ2gY4rlIZeXQWP
D2BtLxxbaXMkODLxoWN42tOf1WyRT7yo2ehg8tx6OnJOemkwE6kPFwg0LuXqWCFcNc6e
hE0df0frtdwPleulWlY4GF3xbOSR2aDJVRD1KdA5jjdFQ6KnBBT6fwqLgrk6Q/rZP98L
+j8O670m19jQD7L3r8BgYLB2JYM9eRAqqcYiMWfqZr928Cd8swDIRj9aoHhT7SYHdSnw
5etdHgD3zwQcuXgeM6iMNEeE2q7m6SsFb5Inb+cl/7x7GUM17fc1ZNrSugpYGrPyDCSg
oGEw==
X-Gm-Message-State: ACrzQf0u+0ERJKdhCDiHZ8Y4XywdMABUNoQKu63Zc6XTC6+WtYM38QH3
Z+S8Col2BwnwyZHA4bcl5xlIG5p1xGo=
X-Google-Smtp-Source: AMsMyM7izrjgEO7Jr6qYFMn1HxK4JrLZurzvOkgM8fxSocbS+vhKiwgRHckEuGaK9CgkVunHuVRa5A==
X-Received: by 2002:a5d:4889:0:b0:22b:214:38dd with SMTP id
g9-20020a5d4889000000b0022b021438ddmr10117009wrq.32.1667256650679;
Mon, 31 Oct 2022 15:50:50 -0700 (PDT)
Received: from krug (87-196-74-163.net.novis.pt. [87.196.74.163])
by smtp.gmail.com with ESMTPSA id
u6-20020a05600c19c600b003c6f8d30e40sm8942207wmq.31.2022.10.31.15.50.49
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 31 Oct 2022 15:50:50 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <5afc446b-3843-8bfc-f51d-713445a9d30f@HIDDEN> (Dmitry Gutov's
message of "Tue, 1 Nov 2022 00:26:43 +0200")
References: <87sfj8umwb.fsf@HIDDEN> <87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
<49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN>
<87k04fvig4.fsf@HIDDEN>
<5afc446b-3843-8bfc-f51d-713445a9d30f@HIDDEN>
Date: Mon, 31 Oct 2022 22:51:59 +0000
Message-ID: <87a65bvc6o.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Dmitry Gutov writes: > On 31.10.2022 22:36, João Távora
wrote: >> Dmitry Gutov writes: >> >>> On 31.10.2022 13:56, João Távora wrote:
>>>> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN
>>>> <mai [...]
Content analysis details: (3.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.221.52 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.52 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 58839
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN,
Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Dmitry Gutov writes: > On 31.10.2022 22:36, João Távora
wrote: >> Dmitry Gutov writes: >> >>> On 31.10.2022 13:56, João Távora wrote:
>>>> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN
>>>> <mai [...]
Content analysis details: (2.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.52 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.221.52 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 31.10.2022 22:36, Jo=C3=A3o T=C3=A1vora wrote:
>> Dmitry Gutov<dgutov@HIDDEN> writes:
>>=20
>>> On 31.10.2022 13:56, Jo=C3=A3o T=C3=A1vora wrote:
>>>> On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmai=
l.com
>>>> <mailto:joaotavora@HIDDEN>> wrote:
>>>> > In the little time I've used this feature since the start of this
>>>> > discussion I have discovered it backfires no small number of occas=
ions:
>>>> > Eglot, CIDER,*scratch*,*ielm*,*sly-scratch*,*Completions*,...=C2=
=A0 Heck
>>>> > even*ibuffer* itself is targeted by this.
>>>> And you can add the gnus mail buffers to this list. If you are
>>>> unlucky
>>>> enough to start M-x gnus from a project file to read your email, then
>>>> closing that project in the future will take your gnus session, your
>>>> summary buffers, messages, etc. with it.=C2=A0 This can't possibly be =
considered
>>>> an exotic use case, and can't be right.
>>> Does Gnus use fundamental-mode for some of its important buffers?
>> No idea. gnus-summary-modes is one of the modes
>> Try:
>> emacs -Q
>> C-x C-f some/file/in/a/project/foo.c
>> M-x gnus ; Remember to check your email
>> ; read mail, make searches, etc
>> C-x b foo.c ; go back to the file
>> C-x p k ; Get preposterous confirmation prompt about tens of buffers abo=
ut to be killed
>> ; say yes, bye all those emails
>
> I suppose it might match
>
> (and (derived-mode . special-mode)
> (not (major-mode . help-mode)))
>
> then.
Whatever it's doing, it's completely wrong and must be fixed. It
probably break other email clients too.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:26:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 18:26:54 2022
Received: from localhost ([127.0.0.1]:42169 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opdF8-0004KG-It
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:26:54 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:41550)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1opdF5-0004K2-Sr
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:26:52 -0400
Received: by mail-wm1-f52.google.com with SMTP id
fn7-20020a05600c688700b003b4fb113b86so8926714wmb.0
for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:26:51 -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=1CdgKWJzXveRpuLFg0+GM8NRAgO0dmhgdGzC7o6qaF8=;
b=g7LE4PCKoUpVkZt3QK333jUVjSA5G7R+JymqUelosqTAXZXHIfo33lSzYCBCYr5E38
XNEaA9hD80V9a6VSh0UrtcPW7dutmG37iIGBGFzHIEJHTqAkwDlwGMrbf6NBwEqEmmEp
DEffvTBY+9YQdiqBmjlMs+NmrPMh9MGWxMtQ/8OLhImEV8UM++1XmlpT+NIGHBNloazs
E74FR/GOLTgrT9xZvSOjWZFjsFUIk2F6DMdOWUXmcATHPHxKdiR9s67rEew4lo804DLa
q4lMtJ/062UAau1O2uDLVuciASDUhuiCKIK8D7197xkoWsfbRReOtBmVEabwuP3J/GyK
8rgQ==
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=1CdgKWJzXveRpuLFg0+GM8NRAgO0dmhgdGzC7o6qaF8=;
b=fIsjQXQNJullghF1Ou0PMEADpiPlNqicQ9n/nOUiQfOXverdiZbTfDQ5WxuLfkEe8u
nWDjzOuE/4hTyZa+kMgM0icH+4wcA7dV9BsV5OEFvuIZu8vVxIKcyBXW7AaHU4+0bbNh
7u+kbIf8AGdIw3R6pJ+7ZNIHEXL6rd0IL82QdspjeLZhVgdByLxbD5llnXMhx5tFrp4O
p2OFxMKCZaGDrP+IkYyzZa5Khabq3azbQ71kcrAEusvZBnFGCzN6whu3BNo34j4l44k9
YOibe4unlhFazN1wc0e3z+GDVBsmjO3X4XkRW2GkaqSe38Pz9asCuFDiZYIHJ391cR55
Xq3g==
X-Gm-Message-State: ACrzQf0COM1BZM6w5LSQadF1yNWAJFAKgqr1dHv1ikgDBLFve4iun4JE
ZKCjyMr2LZJIuFlI+4NeJTw=
X-Google-Smtp-Source: AMsMyM7gSNYFE9clmccbkdb8WBNNAGWr8HHj5zTfmML1M/rH4WYqR57z/AwEftQdtpxlN6eX7KFLQw==
X-Received: by 2002:a05:600c:2287:b0:3cf:4dfb:c223 with SMTP id
7-20020a05600c228700b003cf4dfbc223mr17753265wmf.19.1667255205872;
Mon, 31 Oct 2022 15:26:45 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
by smtp.googlemail.com with ESMTPSA id
q8-20020a5d5748000000b0023677081f3asm8213400wrw.42.2022.10.31.15.26.44
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 31 Oct 2022 15:26:45 -0700 (PDT)
Message-ID: <5afc446b-3843-8bfc-f51d-713445a9d30f@HIDDEN>
Date: Tue, 1 Nov 2022 00:26:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
Content-Language: en-US
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
<CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
<49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN> <87k04fvig4.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87k04fvig4.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 58839
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN,
Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
On 31.10.2022 22:36, João Távora wrote:
> Dmitry Gutov<dgutov@HIDDEN> writes:
>
>> On 31.10.2022 13:56, João Távora wrote:
>>> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN
>>> <mailto:joaotavora@HIDDEN>> wrote:
>>> > 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.
>>> And you can add the gnus mail buffers to this list. If you are
>>> unlucky
>>> enough to start M-x gnus from a project file to read your email, then
>>> closing that project in the future will take your gnus session, your
>>> summary buffers, messages, etc. with it. This can't possibly be considered
>>> an exotic use case, and can't be right.
>> Does Gnus use fundamental-mode for some of its important buffers?
> No idea. gnus-summary-modes is one of the modes
>
> Try:
>
> emacs -Q
> C-x C-f some/file/in/a/project/foo.c
> M-x gnus ; Remember to check your email
> ; read mail, make searches, etc
> C-x b foo.c ; go back to the file
> C-x p k ; Get preposterous confirmation prompt about tens of buffers about to be killed
> ; say yes, bye all those emails
I suppose it might match
(and (derived-mode . special-mode)
(not (major-mode . help-mode)))
then.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 20:57:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 16:57:57 2022
Received: from localhost ([127.0.0.1]:42039 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opbr3-00023l-0V
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:57:57 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:45634)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1opbr0-00023X-QH
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:57:55 -0400
Received: by mail-wr1-f53.google.com with SMTP id y16so17635657wrt.12
for <58839 <at> 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)
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)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> (Dmitry Gutov's
message of "Mon, 31 Oct 2022 19:24:02 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
Date: Mon, 31 Oct 2022 20:58:57 +0000
Message-ID: <87edunvhf2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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 @@ p [...]
Content analysis details: (3.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [209.85.221.53 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.53 listed in wl.mailspike.net]
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
manuel.uberti@HIDDEN, philipk@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 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 @@ p [...]
Content analysis details: (2.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.221.53 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.221.53 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Dmitry Gutov <dgutov@HIDDEN> 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?
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 20:35:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 16:35:43 2022
Received: from localhost ([127.0.0.1]:41946 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opbVW-0001Nr-Mn
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:35:42 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:36592)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1opbVV-0001Nd-3b
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:35:41 -0400
Received: by mail-wm1-f43.google.com with SMTP id
c3-20020a1c3503000000b003bd21e3dd7aso11553846wma.1
for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 13:35:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding: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=dAaX2t/8dsMjjBc30G7/9YJxBbyydyqCZIrzdVt2xL0=;
b=OeRQ2xrkJA8W/5bMW8Y5mudts0D9DdatytCkKb9BPuqX4C2aj6vJFHE6fQV0qwC/zy
JC39CGLZQCZSPw5JlqEXVwe//Pch+DBp8B6b6kCua+wuq1IXLFWIVksKPg7Udt4JwGro
rRS7+ObJD+0j77giRZ1Z1ipZ5M5zRbm2pLtnhJCmdqT12K40ZyZbcjBx/MG6AZtZYohh
vp43z2dr9kOsl0Ij0MEQtS3IZJ3o3Z0SrKfwouxQB43IuaFsqstoZ2oStKOevjHVDZkR
cqn22uhEKkP4+6iTkJyxMCTKjB87+kDqHkX+0OGp11zzwSfPKp/JhvqCkLY6/pOuQ7n6
G2nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding: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=dAaX2t/8dsMjjBc30G7/9YJxBbyydyqCZIrzdVt2xL0=;
b=NxIpq3zPdnI/6hoH53x3PThoujCzYWT5wrtUT6mDU6dPch664ZITPIHh91yenrUWQq
zWEnNs/0Cx2Wl/UCf67mMR86IbTS/lTo51nyqrcw8lTcdE39O1S0z2xUP6YhyyMFLNTr
zAv+y4NkUTUgnUl+wUKNUUPpyDUROQ33P+0uI2Sa31/aLez0+2YxsxTBOrN8Gqi5k+xK
TdwYNFgkENN3BO7biEYq1/yuMDd+fI+mMj0mK3jeD/MkB2CihjzgYM+zaoueA7+wmiL3
TJjP8NV19eI47OYaf5BXISYm/NAwW+prj9mDjNIxZmgqawFQFDIZg3bN2iJOCPuwBsq4
H9DA==
X-Gm-Message-State: ACrzQf0BUrGpBjINmY53gK3fUtlFlh9255zZ5kgAy/PsECWX/VUqryDq
x6mIBPfJJRb5YjtObSalGME=
X-Google-Smtp-Source: AMsMyM7/JrwaY1Jbw+xDKqgMGy2PA8eDmOTWL7UxAHHWNdRKaTrX5sxeav4wPaVaOJLdWgSzWKf7nQ==
X-Received: by 2002:a05:600c:21d7:b0:3cf:7d8a:42e2 with SMTP id
x23-20020a05600c21d700b003cf7d8a42e2mr242171wmj.202.1667248534969;
Mon, 31 Oct 2022 13:35:34 -0700 (PDT)
Received: from krug ([87.196.74.163]) by smtp.gmail.com with ESMTPSA id
w24-20020a1cf618000000b003cf4d99fd2asm8290915wmc.6.2022.10.31.13.35.33
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 31 Oct 2022 13:35:34 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN> (Dmitry Gutov's
message of "Mon, 31 Oct 2022 19:11:33 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
<87v8o0uxn5.fsf@HIDDEN>
<CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
<49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN>
Date: Mon, 31 Oct 2022 20:36:43 +0000
Message-ID: <87k04fvig4.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Dmitry Gutov writes: > On 31.10.2022 13:56, João Távora
wrote: >> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN
>> <mailto:joaotavora@HIDDEN>> wrote: >> > In the little time I've used
this featu [...]
Content analysis details: (3.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.128.43 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.128.43 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 58839
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Dmitry Gutov writes: > On 31.10.2022 13:56, João Távora
wrote: >> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN
>> <mailto:joaotavora@HIDDEN>> wrote: >> > In the little time I've used
this featu [...]
Content analysis details: (2.6 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[209.85.128.43 listed in wl.mailspike.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[209.85.128.43 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[87.196.74.163 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (joaotavora[at]gmail.com)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Dmitry Gutov <dgutov@HIDDEN> writes:
> On 31.10.2022 13:56, Jo=C3=A3o T=C3=A1vora wrote:
>> On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.=
com
>> <mailto:joaotavora@HIDDEN>> wrote:
>> > In the little time I've used this feature since the start of this
>> > discussion I have discovered it backfires no small number of occasion=
s:
>> > Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...=C2=
=A0 Heck
>> > even *ibuffer* itself is targeted by this.
>> And you can add the gnus mail buffers to this list. If you are
>> unlucky
>> enough to start M-x gnus from a project file to read your email, then
>> closing that project in the future will take your gnus session, your
>> summary buffers, messages, etc. with it.=C2=A0 This can't possibly be co=
nsidered
>> an exotic use case, and can't be right.
>
> Does Gnus use fundamental-mode for some of its important buffers?
No idea. gnus-summary-modes is one of the modes
Try:
emacs -Q
C-x C-f some/file/in/a/project/foo.c
M-x gnus ; Remember to check your email
; read mail, make searches, etc
C-x b foo.c ; go back to the file
C-x p k ; Get preposterous confirmation prompt about tens of buffers about =
to be killed
; say yes, bye all those emails=20
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 17:33:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 13:33:45 2022 Received: from localhost ([127.0.0.1]:41678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opYfR-0004KC-6H for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:33:45 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:40901) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opYfO-0004Jx-Uq for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:33:43 -0400 Received: by mail-wm1-f52.google.com with SMTP id v124-20020a1cac82000000b003cf7a4ea2caso664691wme.5 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 10:33:42 -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=N9XlXDeVAZEYgERBqO5Kk0aGERaP1YucMRandt0Cpdk=; b=HTAoFcejJTdlUa3/kBROsfq9b0ftuSdudfekyAp6v9zoghHu5HhCFCXvSvJOvpT1Us NxF85YLeJdDonTdi8I02WcXmBjSsTcyuZREm4CMHfKByVxhun8PA0CvfqjMZr7W17okR uY7OnUKkOfTjh5c2P2CJvLhlACXGtUVqC8eaNCxl4hzm3HJkRUnD90fwCxkZh8tWHhU4 vKIQZrp8iVEv3uUSeuwt7nUPY6FuvGSH6peYCtDc0A7MF3s9DSLncGcvEajmUFJyRFfI gHf/7vm/tjTJvfrVHYJZ2bECM2yNsPFpm2hCSeaAv18wNwXpeMckat+Vq68fv9PyqqoJ KmwQ== 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=N9XlXDeVAZEYgERBqO5Kk0aGERaP1YucMRandt0Cpdk=; b=PlAqwIy3WJUiam6EVd8tEwZsngYjjwZYAFaVMQedJCF+Zq7b94o2OeUXbz403sCpts LHo9op2hKXwEaTS0deiprGEhJiyaEJK2N4+MNEkbbcCzzEBnAAjBTX17b5BffWvCo6NB LutwgZdz97F1SErg7hdbd2rYDeWtRuVtSJCNouYZKP4zFKe1RZ0W9G+J9XXXeU0uHxG9 q6VuTjEovvSE39BECb9nUskhu6K4UEDoZd4z1MZB8i3SMtF/adzgSi7aE1tJBF6pkL+l DAWWn6IoW3VIiE9JrrjjFB65HNBvoSNE39x/DHDJE2V+dneHr4CEGY1KU3zdLvGYyD2q D+pg== X-Gm-Message-State: ACrzQf3vKaA1yIoPa1q9/iA4y459IBejYs62EKWivYh8hb05koKOx3LW hnWSA/r5pxEOrlxGc1K99LI= X-Google-Smtp-Source: AMsMyM7FYffK1MSN46erx+1Wxe2rBcrr1EUa0asr73IM5Wz5VmDDDsXOg7VXaOdQrIyAWnG3yLn9iw== X-Received: by 2002:a05:600c:26cb:b0:3cf:6265:ddc6 with SMTP id 11-20020a05600c26cb00b003cf6265ddc6mr9271523wmv.195.1667237617195; Mon, 31 Oct 2022 10:33:37 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r2-20020adfe682000000b002365b759b65sm7775476wrm.86.2022.10.31.10.33.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 10:33:37 -0700 (PDT) Message-ID: <83071f7d-db56-5017-c47c-e5b069dcf2bf@HIDDEN> Date: Mon, 31 Oct 2022 19:33:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87k04ggixk.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 31.10.2022 16:35, Philip Kaludercic wrote: >> It's quite clear that_some_ non-file-visiting buffers can be considered >> as belonging to a project's working set. But it's very very easy to >> come up with many that cannot be considered so. > I have to admit that I am more and more inclined to make the list a > opt-in thing, where we explicitly mark those major modes that are tied > to a project. The current contents of project-kill-buffer-conditions are more or less that already. With the exception of the 'fundamental-mode' entry which creates an open-ended set. That one we could remove, or tweak by adding a buffer name condition, or a variable lookup. My guess is that nobody will bother with setting the new variable, though (call it 'project-owned' or whatever), because killing project buffers is not an essential need for any 3rd party package, just something nice to have.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 17:24:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 13:24:14 2022
Received: from localhost ([127.0.0.1]:41668 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opYWD-00045Q-Mk
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:24:14 -0400
Received: from mail-wm1-f48.google.com ([209.85.128.48]:44554)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <raaahh@HIDDEN>) id 1opYWB-00045C-EO
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:24:11 -0400
Received: by mail-wm1-f48.google.com with SMTP id
bg9-20020a05600c3c8900b003bf249616b0so8451468wmb.3
for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 10:24:11 -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=Ta2WQZhnjG0Uso3my7ceKcuo6U8JLjjVMTlWcFbr45g=;
b=m+it+D5cDrtyrhvPZ/ekjiRLo2G3f+/mzzvSNP3g41LJabyUH5zR+49leZo1RgMO78
6QLXBVb4NW0FwWkXhTnGD3BiKK0ykKx954hp3TXDczOaoEJ5/pA28zkUdAQCuezdKXRz
2YKTM3Nww93VxCYRhxx/vhiO2CA3jfcXFt43ENuwLKRxhCU50R5HzvjfOH8fb5V5djdj
nUV0h34YccG8eSI3SUZKE9hsnHmZ3JJrEnV4iywNQ5XGDezQ+OP0ZVyEPb3UydQUVF4S
IDZfcIE/VNcRnbxiLNX4iijqMQaqbDuslqiRnUiP0HTuNbO+WLUQb+Tq6OCp6Ppp+f33
ya3g==
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=Ta2WQZhnjG0Uso3my7ceKcuo6U8JLjjVMTlWcFbr45g=;
b=ndj+7gAaxITYRcmGuuE92C3UXvTdZCGqpOUaGU4gbbK5WUjcarffR3qvgFUxF6z5dV
i1UqX1NDsTilHdLYv0Su8btaJXYvGMPUp1JwAlTK6qLfXhJ9bQyExHff8MAXCaNJzZo+
0SJbCEw1hmSAYbLB/wNmVacg3QGGbCwtXzucOYaZCq2rivl0DIJZJgudfaLG6xSu3pzV
UUx94p4k3fp66Dj9qERBsp7++BtVS4ZCYiukJmmf4iDYyXacysa6mQ2UqGN/ZIxwDKF3
vZOtwmfNKrvHwNzeVBrzqwHSStXON52BXe7FoC4ely/bbuKAl4q+NeJ44UHQk5eI2Kjl
WIWg==
X-Gm-Message-State: ACrzQf3K9yLm3ITWHqrzENsm6LUIp9HjtAzvanAElcc9sWuTmLHEeFxR
WjfM5X0C9BDuMCNlfWzNAM8=
X-Google-Smtp-Source: AMsMyM7swsttZIPLfpBG/DqT5CcHxjKWCeWcPoB9/C3eflvtYmMXcycCfm6a6Qwul9oSyS6mcXlvKw==
X-Received: by 2002:a1c:5454:0:b0:3cf:7521:3543 with SMTP id
p20-20020a1c5454000000b003cf75213543mr2713287wmi.172.1667237045157;
Mon, 31 Oct 2022 10:24:05 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
by smtp.googlemail.com with ESMTPSA id
y10-20020a5d620a000000b0023657e1b97esm7744171wru.11.2022.10.31.10.24.04
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Mon, 31 Oct 2022 10:24:05 -0700 (PDT)
Message-ID: <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
Date: Mon, 31 Oct 2022 19:24:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
Content-Language: en-US
To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87v8o0uxn5.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
manuel.uberti@HIDDEN, philipk@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
On 31.10.2022 11:53, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>> Anyway, if we do decide to flip the switch, it should be through
>> project-kill-buffer-conditions, so the user can make a different
>> choice through customization.
>
> project-kill-buffer-conditions doesn't work, I've tried it, it has this
> fundamental-mode thing there that makes it impossible. Supposedly it is
> there to serve some purpose that no-one seems to be able to find a
> argumentative basis for.
What have you tried?
This should take care of the specific complaint about unknown
"invisible" buffers:
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)))
> It's quite clear that _some_ non-file-visiting buffers can be considered
> as belonging to a project's working set. But it's very very easy to
> come up with many that cannot be considered so.
>
> Because "killing buffers" is a destructive operation, being greedy here
> is a really bad design decision, as it catches an arbitrary number of
> unsuspecting extensions off-guard, which have been using earmuffed
> buffers for many years.
>
> All in all, it's like you're making a gun that only backfires 5% of the
> time.
Yours is the first instance so far.
> 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.
> Project-kill-buffers is off. Its intention pretty useful, but its
> implementation is a blunder. The root cause is this overgreedy
> project-buffers. When "killing a project" the echo area asks me if I
> want to kill a number of buffers that I didn't even know I had, because
> of hidden buffers. This cannot be logical and the only way the
> "argument can be made both ways" is out of stubborness.
>
> JSONRPC's buffers are hidden implementation details: the argument that
> they are somehow under the responsibility of project.el just because it
> can see them through (buffer-list) is blind tiranny.
>
> 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.
> diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
> index dc3ed52650..718bebc7cd 100644
> --- a/lisp/vc/vc-dispatcher.el
> +++ b/lisp/vc/vc-dispatcher.el
> @@ -179,6 +179,7 @@ vc-setup-buffer
> (let ((camefrom (current-buffer))
> (olddir default-directory))
> (set-buffer (get-buffer-create buf))
> + (setq-local project-owned t)
> (let ((oldproc (get-buffer-process (current-buffer))))
> ;; If we wanted to wait for oldproc to finish before doing
> ;; something, we'd have used vc-eval-after.
>
> To name one. The above is just the converse of the solution proposed by
> Philip before.
>
> Anyway, I've now suggested and presented 2 actually tested, actually
> working patches to project.el. I don't have anything more to add.
They are not much better than the "patch" I showed for Eglot,
correctness-wise.
And mine would make it safe against any kill-buffer calls, including
ones issued by the user.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 17:11:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 13:11:44 2022 Received: from localhost ([127.0.0.1]:41663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opYK8-0003n7-D7 for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:11:44 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:35755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opYK6-0003ms-Hd for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:11:42 -0400 Received: by mail-wr1-f50.google.com with SMTP id l14so16927903wrw.2 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 10:11:42 -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=LyVOzv8QeL/S6QgA061ar44GGunnx7lR1gbf/9ieroY=; b=S5JT9XNYGn7Qp9lg6l4FlpZNrWZ+4LexSrezoJKRrgcui9kmNOtc0lcfpgWXh26Y2d 2xHBIIe/GsMyqHDnTIq/h3cMmtewO2n0i6l2vAFnMfhNV9FNBFqqMTehwJpLNvcZlpic KApT1wFVjgnKHs+eRukInVZdlB792zDELmUtLH42pKWV2KBbSWvRg2s7XjgEqneybj6W cI02CX8rsA0WgtWoHYJgq9Ya5OBD1lshKceyCxTxW8aqM6is3nY2mPvVG0PTJaZpka4u 2ZFSwpC5LXGKCVjLDo2HLS77aU/AkZgR+WZDLwgvjPhSNDhM373KAwNvC8nhW/y8Vxp6 hA2w== 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=LyVOzv8QeL/S6QgA061ar44GGunnx7lR1gbf/9ieroY=; b=cs2ngiPT13AT6XeO3BEHrJi71tqogTzSc8ldQDH0OjHIoor7jkO0rKPmOsOEvUhf9Y AIEhgE0dAebZTNbM+vMD51PV4qt09fZmpiVuBnlcjQLSJ+2hb2IvC1V7ceaz5iKHISJE 9L0PjLOdMGcFipFEbj0bYkZiHKoiMQdz4+7w6UmL2IVIhy/NcrNyQ4DXt2Acnq022GiP IK5iZuLcwI5LpjuLBE90W2FN4SWbYGiK1XyPDt5sd+S0QTEd/qxuiLaO37F8cQG1sIl1 EM3Jg4sdQlfpU+LGXDtPNtd//tbrwCgQl+eyJRcuuN7gwPRVitslicUja9sI2aou0B64 HTcQ== X-Gm-Message-State: ACrzQf0qjxWf710xFiI8FDMi/z8vK2cM/+QP8dl+/sAun2MEPeaFrAbL lNJ4wMACVsnHaM41LwGDq9o= X-Google-Smtp-Source: AMsMyM5xDBrLd1m1e3uR1MWgi+EqnMy9WiQCMh4dVEtGtAajkJ5QvX1Y02oAtkkfmAAzP5VHYf980A== X-Received: by 2002:adf:dd12:0:b0:236:6ef7:dacf with SMTP id a18-20020adfdd12000000b002366ef7dacfmr8712454wrm.204.1667236296505; Mon, 31 Oct 2022 10:11:36 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n25-20020a05600c181900b003b95ed78275sm7452283wmp.20.2022.10.31.10.11.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 10:11:35 -0700 (PDT) Message-ID: <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN> Date: Mon, 31 Oct 2022 19:11:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 31.10.2022 13:56, João Távora wrote: > On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN > <mailto:joaotavora@HIDDEN>> wrote: > > > 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. > > And you can add the gnus mail buffers to this list. If you are unlucky > enough to start M-x gnus from a project file to read your email, then > closing that project in the future will take your gnus session, your > summary buffers, messages, etc. with it. This can't possibly be considered > an exotic use case, and can't be right. Does Gnus use fundamental-mode for some of its important buffers?
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 14:35:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 10:35:34 2022 Received: from localhost ([127.0.0.1]:41466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opVsz-0003vz-Hm for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 10:35:33 -0400 Received: from mout02.posteo.de ([185.67.36.66]:45545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1opVsx-0003vm-CY for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 10:35:32 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7421F240108 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:35:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667226925; bh=MZlxZc0JHQ+eftJCj5ZFUoUGhtdFEKT4qSATCFIXgLU=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=r9S5l5e0vT7u4w/pvBXfF/sdNg6awTU5fv2u6rUPn1BwuogGCVG/uarzUDnGUIgbE IhrJfmjnK7RnTBjZDikT/NTS2l2BxU2Lg71Tsw46BDCg2Z79i9RbZJ/sa420P+QlIN rKkEV3Q3xzXeQ7C7wyv6BIaFjz4EQppvGF0dyYieuL7+Nkl3yaaEqzLs0ba7QCEAUt /pP8KaugVnPYEy2MF/TgtvsIpvk4JbHdRG5i6FYS2mxXe1CstQJ1Tz3MBZgv2a3j79 +piBo/l5cEXlwSvaAutg6E94vfqOT/ta5uFSkTqJ2/yZBBa/6fJXzId1Inf0pGEkFK hGj7TWPBKn24w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N1G086zMtz9rxF; Mon, 31 Oct 2022 15:35:20 +0100 (CET) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87v8o0uxn5.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Mon, 31 Oct 2022 09:53:50 +0000") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Mon, 31 Oct 2022 14:35:19 +0000 Message-ID: <87k04ggixk.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Dmitry Gutov <dgutov@HIDDEN> writes: > >> Anyway, if we do decide to flip the switch, it should be through >> project-kill-buffer-conditions, so the user can make a different >> choice through customization. > > project-kill-buffer-conditions doesn't work, I've tried it, it has this > fundamental-mode thing there that makes it impossible. Supposedly it is > there to serve some purpose that no-one seems to be able to find a > argumentative basis for. The condition can be written entirely, if we are willing to accept a breaking change. In the case of `project-kill-buffer', this ought to be acceptable if fewer buffers are killed. > It's quite clear that _some_ non-file-visiting buffers can be considered > as belonging to a project's working set. But it's very very easy to > come up with many that cannot be considered so. I have to admit that I am more and more inclined to make the list a opt-in thing, where we explicitly mark those major modes that are tied to a project. > Because "killing buffers" is a destructive operation, being greedy here > is a really bad design decision, as it catches an arbitrary number of > unsuspecting extensions off-guard, which have been using earmuffed > buffers for many years.=20=20 > > All in all, it's like you're making a gun that only backfires 5% of the > time. > > 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. > > Project-kill-buffers is off. Its intention pretty useful, but its > implementation is a blunder. The root cause is this overgreedy > project-buffers. When "killing a project" the echo area asks me if I > want to kill a number of buffers that I didn't even know I had, because > of hidden buffers. This cannot be logical and the only way the > "argument can be made both ways" is out of stubborness. > > JSONRPC's buffers are hidden implementation details: the argument that > they are somehow under the responsibility of project.el just because it > can see them through (buffer-list) is blind tiranny. > > The mini-languages invented in project-kill-buffers-conditions and > project-ignore-buffer-conditions are abominations. If project-buffers > just been conservatively designed, we'd need nothing more than the > existing hooks for the exceptions. *earmuffed* buffers interested in > opting in could declare if it belonged or not in one line.=20=20 What existing hooks? > Just like > > diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el > index dc3ed52650..718bebc7cd 100644 > --- a/lisp/vc/vc-dispatcher.el > +++ b/lisp/vc/vc-dispatcher.el > @@ -179,6 +179,7 @@ vc-setup-buffer > (let ((camefrom (current-buffer)) > (olddir default-directory)) > (set-buffer (get-buffer-create buf)) > + (setq-local project-owned t) > (let ((oldproc (get-buffer-process (current-buffer)))) > ;; If we wanted to wait for oldproc to finish before doing > ;; something, we'd have used vc-eval-after. > > To name one. The above is just the converse of the solution proposed by > Philip before. I would be fine with this in principle, my only worry is backwards compatibility for those who use project.el from ELPA. > Anyway, I've now suggested and presented 2 actually tested, actually > working patches to project.el. I don't have anything more to add. > > Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 11:55:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 07:55:48 2022 Received: from localhost ([127.0.0.1]:39667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opTOO-0003bi-Hl for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 07:55:48 -0400 Received: from mail-oa1-f54.google.com ([209.85.160.54]:37670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1opTOM-0003bW-Mu for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 07:55:47 -0400 Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-12c8312131fso13182078fac.4 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 04:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7aHktoahfqgBVsEg2YhVX+M+qA+YJ+pbz73mCDa2Nrw=; b=jJ1NMRF3GLrCHdiqynjse9yGjrhAU+oOY7/AI6NIcisRUTL3CTci/nRm+mNtjaEVGT K3G7x+TM6UYj6lZuIE7pIcEj8EndlEGXuVaZpLqyZ/MbG/RTqvBUiL3SzLmZDkODa+Yx lIlm3NJ3odbxeKAJH4IgGp+8rAQS2jdDAwHfyLMN6T9/NIhRinBRXcZSg443QErsrrix 9JsT0yk+08H8i2+8Plw2t5gm6WIUazXAfELt3K6IVTeL5OEZFRUpfsnTlwrEMqZC+p11 ne03EKukxA3/FZY11NuTfkmxvXJFB2fobsMH6pZOW9wuWktA5USKqghHjsbQwWOUrbrp 7c5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7aHktoahfqgBVsEg2YhVX+M+qA+YJ+pbz73mCDa2Nrw=; b=li+xPzKXt4ePsGyfFDDLGE/MuLCX529XGoErrqQ5I3Xsd8jjuBxiMipsqAHsfLPz4N GBrnHGD8yvImRUuJAKHf6/N1t2xofEOQt4daUiNRz72t5yinHAzq2juRp2L0RMXoWEIG HeLHTUW101+rlcIjJmGDEiIC+o9jz6y64qu5laa1rKe+YmZaXb/r0J9Mr2amJ4LnEhID CE2j6yio4FpCHPEGyikaKvDw+XIgfQS1jXiyLRzc2gFd074V3sE3L7szc1QuqYGlFlWb GCXcH2QxGyxLhG6pLLj+UAjYoF2HK32ARY08R+FHhpHYoz7q+ylAQPB6mr5Q9NiO2QJJ jVSg== X-Gm-Message-State: ACrzQf3oQIWt10VWdWknP5P419XTyXIqlYtk16b8fP4DCxeU6YAo08K/ 0JclcAGPFKDOce5N5rXHyoyLsw7nTVEkJlLNhfI= X-Google-Smtp-Source: AMsMyM5UuTOp+NxrNdqjubRcY+dfHJmV0Ow18iig7Dyv62eT7nteFYxuno+tuihHJPwvZdXRw29U2QBH13JkRdGeB5w= X-Received: by 2002:a05:6870:2155:b0:13c:8db1:2446 with SMTP id g21-20020a056870215500b0013c8db12446mr8252504oae.171.1667217340648; Mon, 31 Oct 2022 04:55:40 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN> In-Reply-To: <87v8o0uxn5.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Mon, 31 Oct 2022 11:56:39 +0000 Message-ID: <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000005a503705ec534932" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, philipk@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000005a503705ec534932 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN= > wrote: > 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. And you can add the gnus mail buffers to this list. If you are unlucky enough to start M-x gnus from a project file to read your email, then closing that project in the future will take your gnus session, your summary buffers, messages, etc. with it. This can't possibly be considered an exotic use case, and can't be right. Jo=C3=A3o --0000000000005a503705ec534932 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <= <a href=3D"mailto:joaotavora@HIDDEN">joaotavora@HIDDEN</a>> wrote:= <br><br>> In the little time I've used this feature since the start = of this<br>> discussion I have discovered it backfires no small number o= f occasions:<br>> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Compl= etions*,...=C2=A0 Heck<br><div>> even *ibuffer* itself is targeted by th= is.</div><div><br></div><div>And you can add the gnus mail buffers to this = list. If you are unlucky <br></div><div>enough to start M-x gnus from a pro= ject file to read your email, then <br></div><div>closing that project in t= he future will take your gnus session, your <br></div><div>summary buffers,= messages, etc. with it.=C2=A0 This can't possibly be considered<br></d= iv><div>an exotic use case, and can't be right.<br></div><div><br></div= ><div>Jo=C3=A3o<br></div></div> --0000000000005a503705ec534932--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 09:52:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 31 05:52:52 2022
Received: from localhost ([127.0.0.1]:39586 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1opRTP-0004Sv-WD
for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 05:52:52 -0400
Received: from mail-wr1-f47.google.com ([209.85.221.47]:34635)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1opRTM-0004Sf-R5
for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 05:52:50 -0400
Received: by mail-wr1-f47.google.com with SMTP id k8so15193314wrh.1
for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 02:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding: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=2F0/j7sytqCwyqPb67kDkK0cw5qtV+3clP5lHm1eOA8=;
b=LacIoYt+c0wmFz7oDopBo2VrCKfsKdaNaM+wLPG0jiAVHjTGr93Gsg4DfUHR3I2jv+
stFEEpqwXpJhebVqTXiWyCirbE9GaseauC5HWUgnMlvW7muRA4roKR113yub6VgZQXbj
Wr38mnO0ta9AvbTdV+b0eCcGqiwvghj6reZ4XBfxg9SNQ6sh803AukrIQz6l+UlCTFJd
5J3ewp/WjXDgzagyRHwhknXRjbUiM+PgmhZIOEXlqncs02pHm5h26H7hElLa4l29PMs8
Q1qqvmB2UwdxCl4yf7UpMY9lvf5wVHFjPP6viMpwnLZ7yYDszhaKRhdqOFLcS5MJ+Ncf
w8jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding: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=2F0/j7sytqCwyqPb67kDkK0cw5qtV+3clP5lHm1eOA8=;
b=5oxEnizm9gElPv9PiRPBbypSaJRR/y1GOdpgv8yxnHJ1rQB46mX66ysblfdmG8xgkU
A7rPhkI20FkcNCy8+ohLdLoRZCT8yisVyNVGy6Uytq9gxbtCxGAIZYWeOyzH/KjeOZ0Z
2VRu7ZvsHxYsSMJ6yOmAQCbYLvwULDxYOwXpV1h7IlwpRQ7pn88aMOTERAqF/ucGBfwe
t0MDoTOpVBAJexLqKxTcQipAc091a7yW3otojb7ZZ2aU6QoAQXP97dR2/Mv4FqgBd/Gd
8wehgQ1dft/u8TAZGym4s6o79EFXoDYpy/iuYfrmZJl4vLhAJut/6q+N5znRBn2mpsQd
bb6w==
X-Gm-Message-State: ACrzQf2d0AGz+op6QNDQHhuawBx9dkC4153Z0+VMO98ViuZblAodfilf
1MmEWJtq6GjNHmboFMGMuOo=
X-Google-Smtp-Source: AMsMyM7xBkeZ9tN/eS4yv8T1aNB9UZ1TGy0/aVWnUZaYFhz4sCacHME3D11Q+fBrqcBbtKOHE5198Q==
X-Received: by 2002:a05:6000:1f1a:b0:236:ce27:230a with SMTP id
bv26-20020a0560001f1a00b00236ce27230amr1868531wrb.469.1667209962631;
Mon, 31 Oct 2022 02:52:42 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
by smtp.gmail.com with ESMTPSA id
m17-20020a5d56d1000000b0022cc6b8df5esm6621063wrw.7.2022.10.31.02.52.40
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 31 Oct 2022 02:52:42 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> (Dmitry Gutov's
message of "Sun, 30 Oct 2022 17:58:18 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
<877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
<46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
Date: Mon, 31 Oct 2022 09:53:50 +0000
Message-ID: <87v8o0uxn5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org,
manuel.uberti@HIDDEN, philipk@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> writes:
> Anyway, if we do decide to flip the switch, it should be through
> project-kill-buffer-conditions, so the user can make a different
> choice through customization.
project-kill-buffer-conditions doesn't work, I've tried it, it has this
fundamental-mode thing there that makes it impossible. Supposedly it is
there to serve some purpose that no-one seems to be able to find a
argumentative basis for.
It's quite clear that _some_ non-file-visiting buffers can be considered
as belonging to a project's working set. But it's very very easy to
come up with many that cannot be considered so.
Because "killing buffers" is a destructive operation, being greedy here
is a really bad design decision, as it catches an arbitrary number of
unsuspecting extensions off-guard, which have been using earmuffed
buffers for many years.=20=20
All in all, it's like you're making a gun that only backfires 5% of the
time.
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.
Project-kill-buffers is off. Its intention pretty useful, but its
implementation is a blunder. The root cause is this overgreedy
project-buffers. When "killing a project" the echo area asks me if I
want to kill a number of buffers that I didn't even know I had, because
of hidden buffers. This cannot be logical and the only way the
"argument can be made both ways" is out of stubborness.
JSONRPC's buffers are hidden implementation details: the argument that
they are somehow under the responsibility of project.el just because it
can see them through (buffer-list) is blind tiranny.
The mini-languages invented in project-kill-buffers-conditions and
project-ignore-buffer-conditions are abominations. If project-buffers
just been conservatively designed, we'd need nothing more than the
existing hooks for the exceptions. *earmuffed* buffers interested in
opting in could declare if it belonged or not in one line. Just like
diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index dc3ed52650..718bebc7cd 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -179,6 +179,7 @@ vc-setup-buffer
(let ((camefrom (current-buffer))
(olddir default-directory))
(set-buffer (get-buffer-create buf))
+ (setq-local project-owned t)
(let ((oldproc (get-buffer-process (current-buffer))))
;; If we wanted to wait for oldproc to finish before doing
;; something, we'd have used vc-eval-after.
To name one. The above is just the converse of the solution proposed by
Philip before.
Anyway, I've now suggested and presented 2 actually tested, actually
working patches to project.el. I don't have anything more to add.
Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 21:15:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 17:15:25 2022 Received: from localhost ([127.0.0.1]:39086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opFeP-0008Ot-80 for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 17:15:25 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:34304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opFeN-0008Oh-3B for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 17:15:23 -0400 Received: by mail-wr1-f43.google.com with SMTP id k8so13555911wrh.1 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 14:15:23 -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=s66vI+iGALnCuUXaDP3IW2oUHV+PT9mgDpsnLSTdD8U=; b=GvPII1hXmlut2RKJrBsETWRkrdP7j/X+6oPUMoaOokNR/TtaOl5UZ3pEVQOIi394qA 2gGxtn+MPHRNxilpH3wItj7XV0Pc8vbD5nxnGfZyJWlcxqrHI17N/Bq4u/y6KCaAkFy8 BcN4WSL39scHA4ZquW9TJJiJ9A7VLmhgsWLjXccZRsvGrTps++Rn06wFooWBatxWAWck uGW9mgE08r6A9R5QrGHG6K/k2qza+kw1ioKwcDbrtp2TytC8P5vmbPPDzfsCqpuodaM7 9ufZ/hFzrUmh5dUIobSWL3JfBD4uTyfWJMacrs4sb4mdxIvMcytrh43sXNSi6xJqXBWz tJPA== 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=s66vI+iGALnCuUXaDP3IW2oUHV+PT9mgDpsnLSTdD8U=; b=tCO69SusOXUg7/TXIykDg0aroHRurmMbRdEi3kTZ+nY14qbQoVizUhWitl+SWNhRic +oltV4ZQEc0/RCG1ZRC1zYQXxKcehRUNaZ+wHw7QB9O9KslB9T4dtjEurIqkgQMYViir 3E3eWogUvtTiMcio3iNiOyDLgwdqOAm+saw/19cNi6eEoA1+TIfMEBIdiYFGE5NoQZ9M hY/Qct3JHmijRNOyekQRRLG5XxmmwnYQZl/FpRkA5Q7rVsRScDa0tihuUGqWISEVjVZR x0K86QOCkv/lClSXi+reL7+93LhIe+K3HxTzKg0MGyYTsjDUjKrSAUVxThh/EmwMxr5e 13ig== X-Gm-Message-State: ACrzQf0qvkAzXYpfaRMVe4ikiT7YnP6OVLw+nJ3jKqgrQHXiNOS5Ka/I C0kgT5/raOozZecGzERzwdg= X-Google-Smtp-Source: AMsMyM7DZ5EbLllAJm1r91BM+Q/0TKabNevgfbW/hGJ3jtbWjgMbeGFJPefkw5807TMpU+Wr6pnE+Q== X-Received: by 2002:a5d:58d7:0:b0:236:6c53:6123 with SMTP id o23-20020a5d58d7000000b002366c536123mr6004607wrf.719.1667164517200; Sun, 30 Oct 2022 14:15:17 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g4-20020a5d5544000000b002366fb99cdasm5097725wrw.50.2022.10.30.14.15.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Oct 2022 14:15:16 -0700 (PDT) Message-ID: <f9fb2e3e-e9b2-33cb-469b-3e61176c2e65@HIDDEN> Date: Sun, 30 Oct 2022 23:15:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <838rkxfep9.fsf@HIDDEN> <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN> <834jvlf5o4.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <834jvlf5o4.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 30.10.2022 21:54, Eli Zaretskii wrote: > You don't need to be defensive, I did not intend to restart the > argument. I just wanted to inform João that your opinion was and > remains that non-file visiting buffers should be part of the project, > that's all. Thanks. >> The issue Joao is having, however, is with particular "hidden" >> non-file-visiting buffers (in fundamental-mode). And here the argument >> could be made both ways. > He was making a more general argument about buffers that don't visit > files, AFAIU. I wanted to inform him that this idea was already > considered in the past. I don't know if that was his point. To quote: Yes, I think some earmuffed buffers can clearly belong to projects. Others probably not. You haven't seen me complain about project-kill-buffers killing the *EGLOT events* buffer, for example 😉
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 19:55:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 15:55:39 2022 Received: from localhost ([127.0.0.1]:39055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opEPD-0006QK-AD for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:55:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1opEPB-0006Q8-BF for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:55:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1opEOq-0006Mu-J5; Sun, 30 Oct 2022 15:55:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=yi20182JLmgS8czNrddhWJ6mbx69JxkTfgdQSPZDwlM=; b=hodTeXXMhIdZaCWuSbRc wbNrtemxKDcGLrsWvCK1DfHrLo0tmTxrGgeEK70R/Uao9ANnFDQwnpDgroWsIkzuD3qBoWIWqU/Uw Q0mJ1ucZkg5WCZGDhNeFlNEFW1Lh+/fQzdQJhaXHaCY3PYh2m0NcEuy4n3H/L+rQvkrsDC6kLeZeJ T3bWxG4Ng2vYTPVcCxHwPKCQhkmgkZV2ONFW02SzWFvXBUGJxLfun6SeYWTnS51UWsYeXm+2ldAd5 QFe16q5AErtKBr1rL1M0jsqe9eNBXf90dDuCFiz3GcocHmiCfCE6hlFT4Fby/frgTYrc4YEa1spvI yqQZSgb00aIK3w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1opEOj-0006OR-Qo; Sun, 30 Oct 2022 15:55:15 -0400 Date: Sun, 30 Oct 2022 21:54:51 +0200 Message-Id: <834jvlf5o4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN> (message from Dmitry Gutov on Sun, 30 Oct 2022 21:13:51 +0200) Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <838rkxfep9.fsf@HIDDEN> <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 30 Oct 2022 21:13:51 +0200 > Cc: joaotavora@HIDDEN, philipk@HIDDEN, 58839 <at> debbugs.gnu.org, > manuel.uberti@HIDDEN > From: Dmitry Gutov <dgutov@HIDDEN> > > >> Do you have a link to that message? Details matter. > > > > Not anymore, sorry. It doesn't really matter, if you are now okay > > with making buffers that don't visit files by default not belong to a > > project, regardless of their default-directory. > > It would help remind you of the original explanation, instead of putting > me on the defensive. You don't need to be defensive, I did not intend to restart the argument. I just wanted to inform João that your opinion was and remains that non-file visiting buffers should be part of the project, that's all. > The issue Joao is having, however, is with particular "hidden" > non-file-visiting buffers (in fundamental-mode). And here the argument > could be made both ways. He was making a more general argument about buffers that don't visit files, AFAIU. I wanted to inform him that this idea was already considered in the past.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 19:14:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 15:14:02 2022 Received: from localhost ([127.0.0.1]:39019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opDkv-0005MJ-S2 for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:14:02 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:53194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opDkt-0005M5-Nd for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:14:00 -0400 Received: by mail-wm1-f50.google.com with SMTP id l32so6072143wms.2 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 12:13:59 -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=bIIjv5oTgAJFmWnpB2kEzeKUDgoaKEB5Wb0ZOJslAw0=; b=ZjgsmgiR7hkuYLnKfXQhPF4vC15+FRXlt+RQyuTyethi84GbmPma1KK5gcsv7uHEH5 JPxEGBQ+U3pwcVOpI+78wzgMBAV9zkPbzqiTmG6tyRK0uMRUjasnLg80iEJWZqLnpkuB T6u4BDMcZx9y/PfJ5h82QSBh7ZOFhP/mShHMRPUPOrhy8Hvhb44rKGg+nCGoB7BTPZ2X q0Etrv1d69KzjdsQokyGiujldCiNdiUv7879N87jU4Y8DPUfrfLgR1dqR+LYvD+294Tp 4OXGssxjclPyXuEfe9rU5zA36uJFQjliIdzTwXsa3fe3nIFRl2oJU47yW9DcL88BGLlm yjuQ== 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=bIIjv5oTgAJFmWnpB2kEzeKUDgoaKEB5Wb0ZOJslAw0=; b=FYEbahzpeEPY2QohJRvKbABSRU2notmJsoqfvnZNh8LNIH2JQ+HR9PmGmCyLP+GSZO cYWuXB9nr/CDGnogJpgg3roa4Ds1ey6+pCGqcLYPhxkBD14NIP70lbqDpLuQKKKXjsBi 8Aq11F1+jBTCW9psBol2fXMQwrf8s75FPcd7oGUffjDlvYGxymu5jMgmtnouGsxSpfjD 54UjUfjQos1aWZTAlegEyVVA2UtvGBZCvC5q9L8l6Ky/L4KcNc4u7cHQwaCpxUTZvA09 fYBWizlzRh/H3/C8UE8g9vP4H0AoqoPU2hgIEDjtQLGY3evNRwEAbRjzXTIiLJtiOGBf tuQA== X-Gm-Message-State: ACrzQf1hBZ9BdFfy8HTVNRmghgB+wWPqxrglixqMA6ngVCFdd7uDucFI 7kqDHYJqKof1oJ6rV4wqp40= X-Google-Smtp-Source: AMsMyM4KU94J9dSV229BoV2KvmD9t1uF7vgt1GgloJss5l+WhXfWKkLBn4ABviU09Ik+oxmVVVxZuA== X-Received: by 2002:a1c:448b:0:b0:3cf:6fcd:e171 with SMTP id r133-20020a1c448b000000b003cf6fcde171mr1690689wma.163.1667157233625; Sun, 30 Oct 2022 12:13:53 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k3-20020a05600c1c8300b003c6b7f5567csm19859877wms.0.2022.10.30.12.13.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Oct 2022 12:13:53 -0700 (PDT) Message-ID: <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN> Date: Sun, 30 Oct 2022 21:13:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <838rkxfep9.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <838rkxfep9.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 30.10.2022 18:39, Eli Zaretskii wrote: >> Date: Sun, 30 Oct 2022 17:58:18 +0200 >> Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN >> From: Dmitry Gutov <dgutov@HIDDEN> >> >> On 30.10.2022 08:28, Eli Zaretskii wrote: >>>> Those are relatively safe. Then have a buffer-local variable for >>>> packages to opt into -- not opt out of -- your scheme. >>> I believe I made a similar argument with Dmitry back when project.el >>> was added to Emacs. Dmitry didn't like my suggestion back then, and I >>> have doubts that he changed his mind. >> >> Do you have a link to that message? Details matter. > > Not anymore, sorry. It doesn't really matter, if you are now okay > with making buffers that don't visit files by default not belong to a > project, regardless of their default-directory. It would help remind you of the original explanation, instead of putting me on the defensive. And recall the supporting voices from the others in the same discussion. And maybe add the explanation to the docs, if it looks that non-obvious. To reiterate: we usually want to consider VC-Dir, Diff, Dired and Compilation buffers as part of the project. Even though they are not associated with a file. Because 'C-x p b' can be handy to switch to particular one, and 'C-x p k' can clean them up (when you're "closing" the project). People who think differently, can use project-ignore-buffer-conditions and/or use some special backend (probably defined by themselves) that overrides 'project-buffers' with a different logic. The issue Joao is having, however, is with particular "hidden" non-file-visiting buffers (in fundamental-mode). And here the argument could be made both ways.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 16:40:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 12:40:13 2022 Received: from localhost ([127.0.0.1]:38913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opBM4-0001Xz-IW for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 12:40:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1opBM3-0001Xi-C2 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 12:40:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1opBLx-0005RH-C5; Sun, 30 Oct 2022 12:40:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+dUKtceSVd1qBYPUPOyM81hwaxj15Krqx27rEe8uTks=; b=ou0dmKs6nJIL OIWpZNCkNCLtFmCC4ZAZd+kOVQiyukC7e1CcdxT9hF0wHH20H3Ri7N1repqlHzBqVZcZ7hTFXmjM+ DVEdsQgKTkRn5SSalodW1aHFPpeMldlNoPwgZbSCR0FN2a0k6+HBiqmaoYdbqxcE6gK5oERE7ZOrp ptn1jPBBL9OK/pMyUgdtMvAtEonG6iCqeJIFu5CTXhiDf4zjU+WS2oMVSTihS0xSLdRLAyzh9GBzt 4ZCq6RJpLBAycpmGL/Bt4eXlxzYBUvcS7j9of1hgcKe9Fz+gOOI44HuiLWnNrmoZ5ocHhnwLyygGh r/tcDXN6RjGs3v+hMdsL3A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1opBLv-0008Qs-LP; Sun, 30 Oct 2022 12:40:03 -0400 Date: Sun, 30 Oct 2022 18:39:46 +0200 Message-Id: <838rkxfep9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> (message from Dmitry Gutov on Sun, 30 Oct 2022 17:58:18 +0200) Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 30 Oct 2022 17:58:18 +0200 > Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN > From: Dmitry Gutov <dgutov@HIDDEN> > > On 30.10.2022 08:28, Eli Zaretskii wrote: > >> Those are relatively safe. Then have a buffer-local variable for > >> packages to opt into -- not opt out of -- your scheme. > > I believe I made a similar argument with Dmitry back when project.el > > was added to Emacs. Dmitry didn't like my suggestion back then, and I > > have doubts that he changed his mind. > > Do you have a link to that message? Details matter. Not anymore, sorry. It doesn't really matter, if you are now okay with making buffers that don't visit files by default not belong to a project, regardless of their default-directory.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 15:58:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 11:58:29 2022 Received: from localhost ([127.0.0.1]:38877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1opAhg-0006jK-Nz for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 11:58:29 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:41580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1opAhe-0006j6-QS for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 11:58:27 -0400 Received: by mail-wr1-f54.google.com with SMTP id w14so12813482wru.8 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 08:58:26 -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=nOfVDluq/MsMQYBVzTPeDrml2PPyay8VXo8d56s/djk=; b=IbcBkH2GWXtebIOjtIQlsjy+SWzhUIlGzOwyyN4wlPtjJMmlB7xtfsy8zHb9QuIt2h Nmb6sBmwNkeyrtUjJ3qQxGF8Ic5nnxWkqUgZOi/Y+z/og8oGSMvo7lXA10vOjlXxLSl2 Kq72KTaxVoPSp/TLxvutHmwpUIH2a4tOfsNZqCXtv9yrQx1i4RySdF2KhAslebjIbNym cMS4F0AI0fFwVbDlCqkZnXYkBpheuVNUu4yY81Bs7963IDweorSYwwFp58cqclhyRR+D /7pwuYA5wrIXgb9djOPEsC7ICmIllAbVWq7HYXVhZjJbXz8kvPTrq+gH3a/UxaQojyFW gblg== 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=nOfVDluq/MsMQYBVzTPeDrml2PPyay8VXo8d56s/djk=; b=s2ff8cqe0rp0HbRD+C/egv5zhzxU0V+d61JRpbjwd/TjUEF2gFN7nq7rvIvKXjLivY gub/JQ87WWh2Qhou/+niPftTqEhYkZHkVDtBFLGyK3RuHtAJ5TXC8pfUIRd3Ci8jx0w4 XTkkrS32QqCLnOa30gS8LbRaDsPL9XTGZM8jGxcFgRepLeRlXSLW9YlNu7ZBQNKYT+Ra IvrfYXPMWgmUkTJ6tP9SPO5IuLf9RyN8dVF2D7kEysBUFKoLzvJyUbtXWnSgY7kcY9ag epsCplyVIyCFEUVkPoNkq/2aykuPYLuDsUjEMeyCHecWBGTTs/llMlaIGXr7lqeFtWxg 4+BA== X-Gm-Message-State: ACrzQf3BuV/II3GC0hfQRxiWFk8xkKxeekSxd/p5cy2QSiDXo4etUulK URrX4gifq3zBkXB3nR7J2L0= X-Google-Smtp-Source: AMsMyM4r1Dfr+Pl/kOfH+gZHHq69n5J673BQg6uf7wsuLxbsYZRnUU2mmtpoNZninTcopFsV+JgfFQ== X-Received: by 2002:a05:6000:100c:b0:235:6980:aa24 with SMTP id a12-20020a056000100c00b002356980aa24mr5361186wrx.238.1667145500513; Sun, 30 Oct 2022 08:58:20 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c6-20020a056000104600b0022e344a63c7sm4534090wrx.92.2022.10.30.08.58.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Oct 2022 08:58:20 -0700 (PDT) Message-ID: <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> Date: Sun, 30 Oct 2022 17:58:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <837d0hhlke.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 30.10.2022 08:28, Eli Zaretskii wrote: >> Cc: Manuel Uberti<manuel.uberti@HIDDEN>,58839 <at> debbugs.gnu.org, >> Dmitry Gutov<dgutov@HIDDEN> >> From: João Távora<joaotavora@HIDDEN> >> Date: Sat, 29 Oct 2022 23:49:01 +0100 >> >> Have you considered the converse approach which is to be conservative? >> It doesn't have these drawbacks. In your project buffer's bucket put >> only non-earmuffed, non-hidden, file-visiting buffers automatically. >> Those are relatively safe. Then have a buffer-local variable for >> packages to opt into -- not opt out of -- your scheme. > I believe I made a similar argument with Dmitry back when project.el > was added to Emacs. Dmitry didn't like my suggestion back then, and I > have doubts that he changed his mind. Do you have a link to that message? Details matter. Anyway, if we do decide to flip the switch, it should be through project-kill-buffer-conditions, so the user can make a different choice through customization. So far we have 2:1 votes against that, though.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 12:39:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 08:39:39 2022 Received: from localhost ([127.0.0.1]:37494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1op7bH-0007hU-2Z for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 08:39:39 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:37779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1op7bF-0007hH-Kn for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 08:39:38 -0400 Received: by mail-wr1-f46.google.com with SMTP id bs21so12447242wrb.4 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 05:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=Tp6/f3GBOWH9Uk6fZ275wnjaxpeWBB8inbFG1kqVO/U=; b=pnSaXGVcvtZtdv5Ze0+TBFKDpjBUOhRrEk02h7hvHJkMr9gdVS4s1PxNAvTBz+41HA 0S2z4GTgqaMQTHMxb4ZR1F+yL2sA8gMMqq0OqU4mDNi3E9xR9I3r2WElk1oppX8K+Scg AuUNObO82PRW1gIldedf6kYc6DcQzP6VV34PiG1qRj3eI6txybqd6zp6svcPDW4ZEPix JLSpLebjKqlH3W09Pqjxfw6MbYX8xx/CAto9fW0wsLpSyvoJZUu9N4ogDEG2kmDeS/V4 5AAY43tqlJmRcgacdQWgJdowSyA/1tvGmj/nqi9aQJVNj1Zgg1wv2z+/YbVN3UscTnxX Qh2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=Tp6/f3GBOWH9Uk6fZ275wnjaxpeWBB8inbFG1kqVO/U=; b=zG7gGXYvT8UxR7id7gfDGY+xckIkxVFJMnBB6YWrCjDww+yRwWs8BDOo+fuhk4l06t cPLsSV/FfBdziGT5uLsux83Zs+rSN210kDZVEU5iTWwkLLPbQVpqjSdEziomcWfzSAzH TAooohYAEo5ShQhtA6TUinngiM/V5evMFI4+zF9pJ1QHR69f4QXjkzjh788EjNxEI4/W ZczIyQ3nv6j4I+/aH+K9TLS9ve2ovrq7p1jBj83XLe/8mNOjreDuq2oi8GmFKg/5XdVe mZmbNMK8z5NGmiL0w++gfw4vo/hEgE4mqJLSBHjMxpFPCTefMjp4po1wSL0BlND4Pevw h0UA== X-Gm-Message-State: ACrzQf2NfduNvHwHzeA1RFkmrk94jpJIuHuEgCEK7DKo1pbPMzz8mcRz NSivfCg3JvvMDFtJw8aQDZk= X-Google-Smtp-Source: AMsMyM7Oe/WDEGfvs3j/zsQnT/o3nffkl1VI5RtfZ7/sGm4CieItvPO+Uy101JnNJ/8uC0Ihz+hhaA== X-Received: by 2002:a5d:6485:0:b0:236:4ed2:409c with SMTP id o5-20020a5d6485000000b002364ed2409cmr4868788wri.110.1667133571672; Sun, 30 Oct 2022 05:39:31 -0700 (PDT) Received: from krug ([87.196.74.89]) by smtp.gmail.com with ESMTPSA id s12-20020a5d6a8c000000b002364c77bcacsm4099098wru.38.2022.10.30.05.39.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Oct 2022 05:39:31 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <837d0hhlke.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 30 Oct 2022 08:28:33 +0200") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN> Date: Sun, 30 Oct 2022 12:40:41 +0000 Message-ID: <8735b5wkl2.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Have you considered the converse approach which is to be conservative? >> It doesn't have these drawbacks. In your project buffer's bucket put >> only non-earmuffed, non-hidden, file-visiting buffers automatically. >> Those are relatively safe. Then have a buffer-local variable for >> packages to opt into -- not opt out of -- your scheme. > I believe I made a similar argument with Dmitry back when project.el > was added to Emacs. Dmitry didn't like my suggestion back then, and I > have doubts that he changed his mind. I'd just like state, if there was any doubt, that project.el is a fantastic and long-awaited addition to Emacs. The design is generally great and for one it enabled Eglot to integrate very well. So I am quite thankful to Dmitry and its maintainer. The new project-wide commands (project-find-file, project-switch-to-buffer, project-kill-buffers) are really very useful, and I'm learning to use them. But this point of "which buffers belong to projects" seems off. Not by a terrible lot, but definitely off the way it is. This discussion has revealed some of its flaws. There's still time to adjust the design before Emacs 29. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 06:29:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 30 02:29:05 2022 Received: from localhost ([127.0.0.1]:37167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1op1of-0007lW-4d for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 02:29:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1op1ob-0007l0-Kw for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 02:29:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1op1oV-0008UV-4s; Sun, 30 Oct 2022 02:28:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=kM4jVeQ3x0H/D98VhajCCAqPfRHzAwqF1dzf/ODDKNA=; b=sRJvWpntpk0XfSP5cb2+ GHZ1aKe30+R4ogxVLmE6jy3ngZe0l60HqvPi0bVctNBObkUqg9azU5IAPNkrfcfVJcFGmtg/0q+J3 fpi4ltUeM6XBSQMhIdD/JAIBLf8ZSWE8wGI7miNC+Y92MT63tKFbNi9GVPdyGnREaPXj2HSSCqwB+ s6Fdhq3BrMXILCLaxc98EuqNMxFKK9ERvfmw283JmB5y8lw+c3pqiAkDLGdLOZfR7z3bqn6tqI2M+ pi44M+Ey/Yu1LSQBy2uPCC9QNQmrhjpyd/BtCW0NerVQAm7kZaZN5eLCgGo7R77pigTtnd2HAAOlR OV1cXgrokfcWVA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1op1oR-0003IS-W9; Sun, 30 Oct 2022 02:28:54 -0400 Date: Sun, 30 Oct 2022 08:28:33 +0200 Message-Id: <837d0hhlke.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN> In-Reply-To: <877d0iw8iq.fsf@HIDDEN> (message from =?iso-8859-1?Q?Jo=E3?= =?iso-8859-1?Q?o_T=E1vora?= on Sat, 29 Oct 2022 23:49:01 +0100) Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58839 Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, > Dmitry Gutov <dgutov@HIDDEN> > From: Jo�o T�vora <joaotavora@HIDDEN> > Date: Sat, 29 Oct 2022 23:49:01 +0100 > > Have you considered the converse approach which is to be conservative? > It doesn't have these drawbacks. In your project buffer's bucket put > only non-earmuffed, non-hidden, file-visiting buffers automatically. > Those are relatively safe. Then have a buffer-local variable for > packages to opt into -- not opt out of -- your scheme. I believe I made a similar argument with Dmitry back when project.el was added to Emacs. Dmitry didn't like my suggestion back then, and I have doubts that he changed his mind.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 22:48:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 18:48:03 2022
Received: from localhost ([127.0.0.1]:36849 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ooucU-000435-Te
for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:48:03 -0400
Received: from mail-wr1-f45.google.com ([209.85.221.45]:39541)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1ooucQ-00041p-Pv
for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:48:02 -0400
Received: by mail-wr1-f45.google.com with SMTP id o4so11056134wrq.6
for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 15:47:58 -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=qVNF66lFvDjk//LcSLa+Ehje1C6F43ERHyWekT2QQ5g=;
b=NKP2k6ub7V1oWehtZ1HkqnwXyuCmuXIuJJh7oe1UqRQtrNfnxlWVYP4YHtG8jIVDOJ
bKh+/5yNuij2zZMO7MGCfOqtAC/pqt978i28VtinG+pnv9KpBgLAmKQ1Ua3rj9DQm+ia
0PtyAW7Wdjyqa2O04Mzl2IU3XW4mhKkuHLThUG7rlQ5NXxsvq1UcibokDGq/RN4XQLyu
ClmUG9pT9XvBckpfF5k1Nayczo0Ql4eyAzkitKrtAX68+R+i3byQqAXNQwqiDAX+mD0K
IKCGyM4xNmFyKhUFFhi62blHunZZbIvXd1LHsj4mZ+WaNVJlirXMxdStiw/gtyw4/bYH
X+Hw==
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=qVNF66lFvDjk//LcSLa+Ehje1C6F43ERHyWekT2QQ5g=;
b=CMjuOyPluknQl+uOJqtz88Fkp2oBmtsAV1tiT0mRV2qi2uYrE6CpxwXyfWTMxWXKam
lWX/TG4sggRlI4zyMySAN01h1daFaeiYFwEFbRG0xENBKqmsv4si2dajopWP/Ra9A5f5
sfpSPCrlOPNYIXM2QVR7qjb8dMouAx5UgIjM2/hHDeNyiC77jLXpSMok5CgcXhScVhEE
UFngxwy4P4BWUd2oKSfJ9eB1VqZcBi9WYck6cD5FpGld3fSNWLMRjEiL2L/5TABoBLpK
6VCESf49Ycx0s1dAr0snkSIYXsEpI9i8IOXTecB9+fXRmdwAliFgZ0WIwY2AwM0oNfu7
ZeCg==
X-Gm-Message-State: ACrzQf2LZH3SAreQikAdML3AMG0EABZrJtvG+rlAljCK/iN15bkJ5aJS
rPpJcDgxrq+/xXnnZtBRP6FWPnsMeP0=
X-Google-Smtp-Source: AMsMyM5c2JiMFiu17s8RkkC0RJb8reKWmHjY/DWZrXOFZS7XZdzTP8UXaynUIcIjV2a3fb1pSUSeKg==
X-Received: by 2002:a05:6000:1d83:b0:22c:aa0a:12 with SMTP id
bk3-20020a0560001d8300b0022caa0a0012mr3334456wrb.471.1667083672552;
Sat, 29 Oct 2022 15:47:52 -0700 (PDT)
Received: from krug ([87.196.74.89]) by smtp.gmail.com with ESMTPSA id
i10-20020adffdca000000b00236674840e9sm2563463wrs.59.2022.10.29.15.47.51
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 29 Oct 2022 15:47:51 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <87wn8invbx.fsf@HIDDEN> (Philip Kaludercic's message of "Sat,
29 Oct 2022 22:01:06 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
Date: Sat, 29 Oct 2022 23:49:01 +0100
Message-ID: <877d0iw8iq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Philip Kaludercic <philipk@HIDDEN> writes:
> What would be a co-owner?
>
> My view is that project.el is a manager of buffers, but that isn't
> relevant anymore.
You almost answered the question. There is more than one manager of
buffers. Ibuffer manages buffer, M-x buffer-list, the user. Eglot
manages some normal source code buffers in a co-owned way.
In contrast, the JSONRPC stdout and stderr hidden buffers are managed by
no-one else other than jsonrpc.el: they're not co-owned.
> Project.el uses the same condition format like `buffer-match-p', which
> is quite flexible. Maybe all earmuffed buffers should be spared
> ("\\`\\*.+\\*\\'"), but in my experience that can be too lenient.
Yes, I think some earmuffed buffers can clearly belong to projects.
Others probably not. You haven't seen me complain about
project-kill-buffers killing the *EGLOT events* buffer, for example ;-)
That is not a hidden/private buffer, so I accept that other buffer
managers kill it.
> I have to still admit that I am uncertain if the general ignoring of all
> hidden buffers is justified.
Notice that the patch is more tame: only hidden buffers without
buffer-file-names are exempted from project-buffers.
> I have certainly used hidden buffers
> frequently enough but never assumed that they were outside of anyone's
> control.
What have you used them for?
> They are just regular buffers with a special kind of name
> after all.
I don't know any "irregular" buffers, but yes, that is their
representation. This representation is an old convention in Emacs for
"out of bounds" and "out of sight".
> We ought to be able to define a cleaner way of clarifying what buffers
> can and cannot belong to projects.
Agreed.
> Personally I think a buffer-local variable/predicate would be a better
> approach.
You can think about new conventions and protocols but you force it down
existing package's throats. That doesn't go well as this bug shows.
That's because there are many diverse packages out there, that you can't
possibly know about and they likely aren't tracking your developments
and your thinking.
Have you considered the converse approach which is to be conservative?
It doesn't have these drawbacks. In your project buffer's bucket put
only non-earmuffed, non-hidden, file-visiting buffers automatically.
Those are relatively safe. Then have a buffer-local variable for
packages to opt into -- not opt out of -- your scheme.
As project.el and its new commands gain popularity (I hope it does) then
more and more packages, major-modes, etc will want to buy into its API
and add a little (setq-local project-owned t) when they setup their
helper buffers. It takes a bit more marketing work, but in the end it's
better.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 22:01:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 18:01:19 2022
Received: from localhost ([127.0.0.1]:36838 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oottH-00026Z-0a
for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:01:19 -0400
Received: from mout02.posteo.de ([185.67.36.66]:59873)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <philipk@HIDDEN>) id 1oottF-00026L-AQ
for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:01:18 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 6976A240107
for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 00:01:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1667080871; bh=nip3pJXsfQZt8en4sN8DUdAH/1hERr5BIur8uZXdTG4=;
h=From:To:Cc:Subject:Autocrypt:Date:From;
b=Wk2VWnj+pbmxa1y/Bi/OApj9Ac6c0NGSxvVGKbacxh6sZAYjXDxb3wvD7L0pvCMGF
0JzqTeDrQx58teJyxV5d08LhiaWsYsCGXtQd2Bw5JvmdlyyNSgjwJ8TKf83WWQPpKT
yeGQyZjGwbpxSR+0O+Ghx5+OsOEwJ5WVg1gdaJgcJXsXbZDWVyU07PYPLRxb9uRN7I
II/R9U4Bx6RSPpPa7Q1ZIFcB86WR7JfvjkCFg82xBYGQKS7JMQTbd80+L0+zMzEpPS
K6XGNxfWBcC6+9fC/Qt7IUlOHGUQKk1cnvJU1USLKGh+ix3+VvyCuKv+TP1FooskxG
owdz+FLJqm6Tg==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4N0CzS08Gkz6tpL;
Sun, 30 Oct 2022 00:01:06 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <87eduqwekz.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?=
=?utf-8?Q?a=22's?= message of "Sat, 29 Oct 2022 21:38:04 +0100")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
<87eduqwekz.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Sat, 29 Oct 2022 22:01:06 +0000
Message-ID: <87wn8invbx.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> Philip Kaludercic <philipk@HIDDEN> writes:
>
>>> bytes, but it shouldn't rely on their values and certainly can't free()
>>> what it didn't malloc().
>> But to extend this metaphor, if I kill a programm that allocated malloc,
>> I would expect that memory to be cleaned up.
>
> Yes, but to kill a process you have to own it. project.el is not the
> owner (not even a co-owner) of Eglot LSP internal buffers, and so it
> can't kill them.
What would be a co-owner?
My view is that project.el is a manager of buffers, but that isn't
relevant anymore.
>>> I think the command is pretty useful. But perhaps, I'm just guessing
>>> here, Philip is focusing too much it as if it were the only sanctioned
>>> way for Emacs users to stop working on a given set of files in a
>>> programming project and clean up.
>> Of course it isn't, it is just my prefered way and Eglot breaks it.
>
> I don't think we should play the who-broke-what game. It doesn't help,
> and if we decided to look up the dates of introduction of your
> project-kill-buffers way and eglot's process management, we might reach
> a different conclusion.
I really just meant "break" as in works until Eglot is enabled, and
nothing more than that.
>>> Neither do I. But when I M-x cd to other places, project.el thinks that
>>> scratch belongs to that project. It doesn't, I keep stuff of various
>>> projects in it.
>>
>> I agree, this is bad, but that can easily be solved by adding
>> `lisp-interaction-mode' to the list of major modes that are not
>> killed.
>
> Also *ielm*, the global Elisp repl created by M-x ielm. has the same
> problem. And *Completions*. I'm quite sure that *sly-scratch* in the
> SLY CL IDE would also be targeted. And the CIDER Clojure IDE, as
> someone has already reported. And probably many more. This blanket
> default-directory heuristic is practical in some common cases but flawed
> in many others.
Project.el uses the same condition format like `buffer-match-p', which
is quite flexible. Maybe all earmuffed buffers should be spared
("\\`\\*.+\\*\\'"), but in my experience that can be too lenient.
>>> Just commit the original tested patch I gave you that exempts hidden
>>> buffers without buffer-file-name from project-buffers. Philip's command
>>> will keep working perfectly and we can close this bug.
>>
>> So if I understand correctly, with `eglot-autoshutdown' enabled as soon
>> as all the buffers have been killed, the server will also shut down,
>> right?
>
> Yes! This is exactly what the docstring says:
>
> eglot-autoshutdown is a variable defined in `eglot.el'.
>
> If non-nil, shut down server after killing last managed buffer.
Ok, great.
>> Regarding the patch itself, I think it would be better to use
>> `project-kill-buffer-conditions', so that if a project.el backend
>> defines a new implementation for `project-buffers', the issue doesn't
>> pop up again.
>
> Your concern is quite valid. Fortunately, CLOS generic functions have
> us covered. This is even simpler than the first patch:
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..f8190eb1fc 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -362,6 +362,13 @@ project-buffers
> (push buf bufs)))
> (nreverse bufs)))
>=20=20
> +(cl-defmethod project-buffers :around (_project)
> + "Ensure hidden/private buffers do not belong to PROJECT."
> + (cl-remove-if-not (lambda (b)
> + (and (string-prefix-p " " (buffer-name b))
> + (not (buffer-file-name b))))
> + (cl-call-next-method)))
> +
> (defgroup project-vc nil
> "Project implementation based on the VC package."
> :version "25.1"
I have to still admit that I am uncertain if the general ignoring of all
hidden buffers is justified. I have certainly used hidden buffers
frequently enough but never assumed that they were outside of anyone's
control. They are just regular buffers with a special kind of name
after all.
We ought to be able to define a cleaner way of clarifying what buffers
can and cannot belong to projects. Personally I think a buffer-local
variable/predicate would be a better approach.
> Note this still leaves the *scratch* and *ielm* and other things
> uncovered. It addresses this specific bug and most importantly doesn't
> blow up in the users.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 20:37:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 16:37:05 2022
Received: from localhost ([127.0.0.1]:36772 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oosZk-0008L3-KA
for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 16:37:05 -0400
Received: from mail-wr1-f50.google.com ([209.85.221.50]:45941)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1oosZh-0008KR-Rk
for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 16:37:02 -0400
Received: by mail-wr1-f50.google.com with SMTP id y16so10782466wrt.12
for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 13:37:01 -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=S0ouhzMDaqav1T/5iCcQZG2iVhgyQDI0e+eQU6vfY9E=;
b=qNLd4EcNO40+O9AYVps0Plyp88JHPRIt/zmoJCBXWfrmf1AddzGykFwwtjJjXGewDk
212BMldZ/3/W/YQ4sfamBq1RUq+l3cX4Jaa4hAvkfa86YqBS9Tj6BfOVh7BIs5CyWOb+
AB2zXR7uEg5BhW1wvCk9vQEnawLaDm8DdRmF9vHShfWrdW46cJlrcznpdDhh1NsrbNCy
O447yepAKQXSnVbhY5N+8CfO2ek3xFwNh7Wx3bvXrkHOJ/8DI57p8mO0q18dKZhIb+rs
1iCYiTxgcfggJPxMISwNrjyhb9xO2ySQHDRf/TLO+V7I9SyjGtEJbFMX9ifYfAfZFkS1
48oQ==
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=S0ouhzMDaqav1T/5iCcQZG2iVhgyQDI0e+eQU6vfY9E=;
b=FtU6RFiDXlARz/OzC9SYs43MCi6klMMkGlMrtVm9NkkNW0lfQ6hpINhvOJrCWHhSLr
wcgE2rI4xpGa1ghYSFcq45077fjO0iheC3KEaXcHjePk/RkHJVk4MhVMkELWyeftUn4W
TUhHb4nsjyjE01siM+yBDwMM9N9p04Sxe8+axOrZckiOW6sZQ5pNvWum14sp4H2vprI2
/otA0hKszgiLG2TimzhTx7m5LuYY0hVO9T3V+/h2JgE77bLSkKnyyRZ+lN9uduI38pO8
bxn1gSfRTBpIcHLFUzajlFZB8aRh0+6j4/Mr4/cbCrnjFhb+1Ebaey2yvOqwEwo8WUIH
QSzw==
X-Gm-Message-State: ACrzQf0vBp2xPtJgu9SlcUNdMaExOEnZQVk5i2ftuePxNNYzDmyUSsTC
pUv9moZfXtf1VSPK12OW/ALV5p9hgDg=
X-Google-Smtp-Source: AMsMyM4968E4aLqNhVg/dPP61yor3/c0YSPlmXhACQh813mOGgCX39DrRH7W0/imzue6gyQozzKtYQ==
X-Received: by 2002:adf:e385:0:b0:236:91a6:bd1b with SMTP id
e5-20020adfe385000000b0023691a6bd1bmr3230197wrm.278.1667075815494;
Sat, 29 Oct 2022 13:36:55 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
by smtp.gmail.com with ESMTPSA id
bj29-20020a0560001e1d00b002366b241cf3sm2352665wrb.35.2022.10.29.13.36.54
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 29 Oct 2022 13:36:54 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Philip Kaludercic <philipk@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <871qqq7l9p.fsf@HIDDEN> (Philip Kaludercic's message of "Sat,
29 Oct 2022 14:32:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
<87zgdfwkle.fsf@HIDDEN>
<8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
<87v8o3wgq1.fsf@HIDDEN>
<ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
<87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
Date: Sat, 29 Oct 2022 21:38:04 +0100
Message-ID: <87eduqwekz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org,
Dmitry Gutov <dgutov@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Philip Kaludercic <philipk@HIDDEN> writes:
>> bytes, but it shouldn't rely on their values and certainly can't free()
>> what it didn't malloc().
> But to extend this metaphor, if I kill a programm that allocated malloc,
> I would expect that memory to be cleaned up.
Yes, but to kill a process you have to own it. project.el is not the
owner (not even a co-owner) of Eglot LSP internal buffers, and so it
can't kill them.
>> I think the command is pretty useful. But perhaps, I'm just guessing
>> here, Philip is focusing too much it as if it were the only sanctioned
>> way for Emacs users to stop working on a given set of files in a
>> programming project and clean up.
> Of course it isn't, it is just my prefered way and Eglot breaks it.
I don't think we should play the who-broke-what game. It doesn't help,
and if we decided to look up the dates of introduction of your
project-kill-buffers way and eglot's process management, we might reach
a different conclusion.
>> Neither do I. But when I M-x cd to other places, project.el thinks that
>> scratch belongs to that project. It doesn't, I keep stuff of various
>> projects in it.
>
> I agree, this is bad, but that can easily be solved by adding
> `lisp-interaction-mode' to the list of major modes that are not
> killed.
Also *ielm*, the global Elisp repl created by M-x ielm. has the same
problem. And *Completions*. I'm quite sure that *sly-scratch* in the
SLY CL IDE would also be targeted. And the CIDER Clojure IDE, as
someone has already reported. And probably many more. This blanket
default-directory heuristic is practical in some common cases but flawed
in many others.
>> Just commit the original tested patch I gave you that exempts hidden
>> buffers without buffer-file-name from project-buffers. Philip's command
>> will keep working perfectly and we can close this bug.
>
> So if I understand correctly, with `eglot-autoshutdown' enabled as soon
> as all the buffers have been killed, the server will also shut down,
> right?
Yes! This is exactly what the docstring says:
eglot-autoshutdown is a variable defined in `eglot.el'.
If non-nil, shut down server after killing last managed buffer.
> Regarding the patch itself, I think it would be better to use
> `project-kill-buffer-conditions', so that if a project.el backend
> defines a new implementation for `project-buffers', the issue doesn't
> pop up again.
Your concern is quite valid. Fortunately, CLOS generic functions have
us covered. This is even simpler than the first patch:
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..f8190eb1fc 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -362,6 +362,13 @@ project-buffers
(push buf bufs)))
(nreverse bufs)))
+(cl-defmethod project-buffers :around (_project)
+ "Ensure hidden/private buffers do not belong to PROJECT."
+ (cl-remove-if-not (lambda (b)
+ (and (string-prefix-p " " (buffer-name b))
+ (not (buffer-file-name b))))
+ (cl-call-next-method)))
+
(defgroup project-vc nil
"Project implementation based on the VC package."
:version "25.1"
Note this still leaves the *scratch* and *ielm* and other things
uncovered. It addresses this specific bug and most importantly doesn't
blow up in the users.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 14:33:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 10:33:11 2022 Received: from localhost ([127.0.0.1]:36304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oomta-0002hn-HG for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 10:33:10 -0400 Received: from mout01.posteo.de ([185.67.36.65]:41713) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oomtV-0002hG-VZ for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 10:33:08 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id EE0C1240026 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 16:32:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667053980; bh=S2Rv0NtXlcFjdeTC3LBawUbreaRVfgYv67zAmJ0gFoY=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=gxElmpWRHJYBTzM2HV0/m755sROgtM/TgV68QtGLFYd8bu35+FXLu7EWuXZR6q4yt gGY4J9EIfUnX4F7RZMVQ8fiuHrtTmQJEh/27vpanCDqSPidmcNA66Z1mDT8I8/rRwL Zv6zG2ZbhHG3a7kN/jyPEe6Ti/LY6AmA7G7vt4SNUae5Of1mAtySoxam5uZgMqQ9xS 69UoAMqDwrsufaL0lv7Rjb47TW2jBAuhfZUOaw669k1Bf6GAv8nl+KZqEtdlwwH9tY y+Kdu29WftQxEs8u5UezLHF8283ze0qEAGKGwmfrXtrr/DKwb3wy10cJuM5/M/I9RV c6RQawfsyqDbA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N022L4jLxz9rxF; Sat, 29 Oct 2022 16:32:56 +0200 (CEST) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87ilk2x1si.fsf@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Sat, 29 Oct 2022 13:16:45 +0100") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Sat, 29 Oct 2022 14:32:50 +0000 Message-ID: <871qqq7l9p.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Dmitry Gutov <dgutov@HIDDEN> writes: > >> 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 think this discussion is about mistaking resource access for resource > ownership. Just because project.el or any Lisp package can access the > full list of buffers, doesn't mean it can do whatever it wants with > them. Just like a routine in a C program can see the full memory > address space of the process, and possibly even form pointers to these > bytes, but it shouldn't rely on their values and certainly can't free() > what it didn't malloc(). But to extend this metaphor, if I kill a programm that allocated malloc, I would expect that memory to be cleaned up. >> 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. > > I think the command is pretty useful. But perhaps, I'm just guessing > here, Philip is focusing too much it as if it were the only sanctioned > way for Emacs users to stop working on a given set of files in a > programming project and clean up. Of course it isn't, it is just my prefered way and Eglot breaks it. > So project-k-buffers is useful but it doesn't have that exclusive. If it > did (but I don't think it will ever have) then Eglot could indeed attach > connection management to it. > >> Most object types are garbage-collected when no live reference to them >> remains. That's not the case for buffers. > > Because there is always at least one live reference to them, obviously. > But why does this matter? In this buffer's case there are probably even > more. One of these references is the one that Eglot and Jsonrpc control > the program or network process. This is held in global variable. There > are no resource leaks, as far as I know. > >> 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. > > Are you sure? Well you should actually try M-x eglot-shutdown and see > what happens then :-) > >>> 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. > > Neither do I. But when I M-x cd to other places, project.el thinks that > scratch belongs to that project. It doesn't, I keep stuff of various > projects in it. I agree, this is bad, but that can easily be solved by adding `lisp-interaction-mode' to the list of major modes that are not killed. >> 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. > > Why should resource owners go to the hassle of whitelisting themselves > from other packages' newfound disregard for private property? Not to > mention jsonrpc.el wants its buffers to be killed in controlled > circunstances. So now it would have to "unprotect itself" in those > places. I can't even think of adjectifying this design, let alone deal > with the corner cases. > >>>>> So please consider fixing this in project.el. As Manuel pointed out, >>>>> the venerable ibuffer.el's ibuffer-kill-filter-group also kills proje= ct >>>>> 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-2= 053395 >> >> It's a reasonable approach too. Just not the one we took here. It >> would make sense to try to make it work first. > > Ibuffer understands ownership, so it comes with bug-free and > hassle-free. Sounds more than "reasonable" to me. > > Just commit the original tested patch I gave you that exempts hidden > buffers without buffer-file-name from project-buffers. Philip's command > will keep working perfectly and we can close this bug. So if I understand correctly, with `eglot-autoshutdown' enabled as soon as all the buffers have been killed, the server will also shut down, right? Regarding the patch itself, I think it would be better to use `project-kill-buffer-conditions', so that if a project.el backend defines a new implementation for `project-buffers', the issue doesn't pop up again. > Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 12:15:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 08:15:44 2022 Received: from localhost ([127.0.0.1]:35095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ookka-0007Py-8L for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 08:15:44 -0400 Received: from mail-wm1-f53.google.com ([209.85.128.53]:35426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1ookkY-0007Pk-19 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 08:15:43 -0400 Received: by mail-wm1-f53.google.com with SMTP id m29-20020a05600c3b1d00b003c6bf423c71so8075235wms.0 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 05:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=JflwJd7AS12iBK+7GwmZL4ehrIH1iabfdwaZNuJowqE=; b=K0tBLKI/Vc718Re69xv6/R3e+uZ/YSMOwn0GqhKk7lSzNEj26vTzv4Im/3KLrgjT9V +WtVboBUGio6oE4aqZSbQZXsbl1aDdp1AJoZS1kRapC9cKu1Cab3JaIWz66xFuJijTmd Ax2CaH9LmuhaaM5tJsYylfObt/xxagxWY+ZNYoRHZ6JGZ9hwMOyJYoE1DuGrMVjXwctr fdXSJV/yOmxugNp4EmrmfTIOA/of3m5vypzR1fF/VMHoAkTp3CULwqTI17Ooz6w8QmqF jlOeUki65/udXhbiCF7UwbzJJl62DBePe2INs5ULUeB35RZXRmSw5ThXeJlyTcUhNm2O Z+cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=JflwJd7AS12iBK+7GwmZL4ehrIH1iabfdwaZNuJowqE=; b=wMEBmniNRC26nBrNQqfXR5FNKfyJ3yNlyfp5hzsdaEsAbChwgtBWndCYH7B3gg4qRl 5ULIYk4P/advhn9gmotYIeVvD97sCjFqkdYIuo3hEMWuAYCPbu/iS3AH+qNph4NocYSj RxaztNlrdXKyzhRRBN+ToEGdvpSpf7inwgJS1Kzwb83HVNGdXPNafMfUJNX/q4Ip6T2d TAQXBeYoP2pSaChOVMRJkPV3VozMsLJ61eOS1iUBEb49LX8gGWDeQG8lD/Xam4gTFkEA ChyyXIlnlKtyiASTAuXl956RK9fvhyldtQbfstWT1ivhyzlZ9J+Ek7RswAVJ/vGy80RH uUSw== X-Gm-Message-State: ACrzQf2lDz2fR34SO4l1Dy92BPOZ28FvRcxFOB0hn194QxP/GCL8HWwc PrjiJchJ7sGfDfYt9wegC1xTMccYJiA= X-Google-Smtp-Source: AMsMyM4xlFrLbJqVeNMVYbslMfZPKtsaavdFzbAFds4qZd/p7K7xcvScfyREuqLdTEa5D3bcbfeSBw== X-Received: by 2002:a05:600c:689b:b0:3c2:fd6e:1fe5 with SMTP id fn27-20020a05600c689b00b003c2fd6e1fe5mr2287764wmb.99.1667045735682; Sat, 29 Oct 2022 05:15:35 -0700 (PDT) Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89]) by smtp.gmail.com with ESMTPSA id bx7-20020a5d5b07000000b00228cbac7a25sm1367717wrb.64.2022.10.29.05.15.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Oct 2022 05:15:35 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> (Dmitry Gutov's message of "Sat, 29 Oct 2022 14:27:31 +0300") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> Date: Sat, 29 Oct 2022 13:16:45 +0100 Message-ID: <87ilk2x1si.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > 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 think this discussion is about mistaking resource access for resource ownership. Just because project.el or any Lisp package can access the full list of buffers, doesn't mean it can do whatever it wants with them. Just like a routine in a C program can see the full memory address space of the process, and possibly even form pointers to these bytes, but it shouldn't rely on their values and certainly can't free() what it didn't malloc(). > 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. I think the command is pretty useful. But perhaps, I'm just guessing here, Philip is focusing too much it as if it were the only sanctioned way for Emacs users to stop working on a given set of files in a programming project and clean up. So project-k-buffers is useful but it doesn't have that exclusive. If it did (but I don't think it will ever have) then Eglot could indeed attach connection management to it. > Most object types are garbage-collected when no live reference to them > remains. That's not the case for buffers. Because there is always at least one live reference to them, obviously. But why does this matter? In this buffer's case there are probably even more. One of these references is the one that Eglot and Jsonrpc control the program or network process. This is held in global variable. There are no resource leaks, as far as I know. > 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. Are you sure? Well you should actually try M-x eglot-shutdown and see what happens then :-) >> 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. Neither do I. But when I M-x cd to other places, project.el thinks that scratch belongs to that project. It doesn't, I keep stuff of various projects in it. > 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. Why should resource owners go to the hassle of whitelisting themselves from other packages' newfound disregard for private property? Not to mention jsonrpc.el wants its buffers to be killed in controlled circunstances. So now it would have to "unprotect itself" in those places. I can't even think of adjectifying this design, let alone deal with the corner cases. >>>> 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-20= 53395 > > It's a reasonable approach too. Just not the one we took here. It > would make sense to try to make it work first. Ibuffer understands ownership, so it comes with bug-free and hassle-free. Sounds more than "reasonable" to me. Just commit the original tested patch I gave you that exempts hidden buffers without buffer-file-name from project-buffers. Philip's command will keep working perfectly and we can close this bug. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:27:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 07:27:43 2022 Received: from localhost ([127.0.0.1]:35043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ook06-0003yN-Pe for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:27:43 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:54833) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1ook03-0003y5-7A for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:27:41 -0400 Received: by mail-wm1-f52.google.com with SMTP id t1so877760wmi.4 for <58839 <at> 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) 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) Message-ID: <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> Date: Sat, 29 Oct 2022 14:27:31 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87v8o3wgq1.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) 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?
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:11:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 07:11:29 2022 Received: from localhost ([127.0.0.1]:35037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oojkP-0003aO-4k for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:11:29 -0400 Received: from mail-ot1-f44.google.com ([209.85.210.44]:45667) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oojkN-0003aB-HK for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:11:28 -0400 Received: by mail-ot1-f44.google.com with SMTP id m5-20020a9d73c5000000b0066738ce4f12so4334467otk.12 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 04:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wGKttaIpEohh81NSTR4BbhLEmFkhEhmEQDPfteoV32U=; b=VdBoSyzWtmSplvwWfmR83qwQiERoMpsbipC4sJAXArfXbmoNGVuGPNAhP91BOY3K/L BGz4Fkn8YHxGfOvCDbZp5LyzfabJi2vGMWaIVIPHewLykcloZI6NiZqVjH58mKF0wdnv w4NHHaHJZ7Z/fCfL/TLQ+TRovcFJcrdzVVA6a3y9E3O1Jd4k4ZaXFi7HhcjcqsO4EU3E BD0/0OTSLUWAQUY9Mm44dPDYv4a/LBEe3kG/4I1FOxsyAVPVnrldSi6/zXZjCT+q7xp2 oZ7MezkkWvethabRjI4xZZ1ZLNehC84WTxU2Ky4V0qDLosSTGys3bLCgoh0ZAk56KNTd SrcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wGKttaIpEohh81NSTR4BbhLEmFkhEhmEQDPfteoV32U=; b=MSfS/0Xd+Hx3X1uiV8xd1olnZybB0vPj/J6DI/EZpR+/10CKs/EFGtquWBCyfu68rQ gm220/Wm6pK4CipdeF/XUdvEgQOM35BNo0rSf0FXH09mgHV1QWwycUsWlNCZmrPyvB7q hE2Jqj5X10g+xSkXVNn9hOGZbO51dXWnpWtj+Br2qOTu8HOR/yUjYqP8OikQlG8kOnju bwvthZgeRv3EfKta4YLQf7+f4K5NEV0HrIChpX7PR1Uwq0yust4vPiKrHFWbI5TrfuvF 4z8ry9a70dwUZkLircmePCcFDNTnXXR+VQuIKhveoBLL8nAf1D1BBxwcVe+arjjJ57L4 5QFw== X-Gm-Message-State: ACrzQf3RYlckBE6LjOakVNYEyoIHPJ4PtDM5LbgkFiyQswX4d4uMllva IhcPnkxC7HC2M+jkJqGJ3xwTomwNxZ9uJB4Glqo= X-Google-Smtp-Source: AMsMyM48oGcAeXaFj8DwLGCADnM/Z5Onah4XI8a64JnH63UMYInCb4qIEfEXQqn05t0l6L4XNa4FNm4kkdwNrdBj9pQ= X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id 23-20020a9d0117000000b00666e09d577emr1865207otu.93.1667041881872; Sat, 29 Oct 2022 04:11:21 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87czab16em.fsf@HIDDEN> <5ea24d00-2461-7901-86d6-6bdb01f30020@HIDDEN> In-Reply-To: <5ea24d00-2461-7901-86d6-6bdb01f30020@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 29 Oct 2022 12:12:22 +0100 Message-ID: <CALDnm505G7NY+qWLiTA69D6FZZfX1L9OtTf=TGADBEqKDeHKOA@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Dmitry Gutov <dgutov@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000031db9105ec2a6f33" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000031db9105ec2a6f33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 29, 2022 at 11:59 AM Dmitry Gutov <dgutov@HIDDEN> wrote: > On 29.10.2022 09:38, Philip Kaludercic wrote: > >> 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. > > In that case I think a kind of "project reference counter" should ensur= e > > that the server is only then killed when the last project using it is > > killed (and the right user options are set). > > I suppose. But that kind of arrangement would require a project-specific > hook. > There isn't any one-to-many correspondence between LSP servers and projects. I don't envision adding that to Eglot anytime soon: it seems completely useless. So what problem are you even solving with this "reference counter" talk? Jo=C3=A3o --00000000000031db9105ec2a6f33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Sat, Oct 29, 2022 at 11:59 AM Dmitry Gutov <<a href=3D"mailto:= dgutov@HIDDEN">dgutov@HIDDEN</a>> wrote:<br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex">On 29.10.2022 09:38, Philip Kaludercic wr= ote:<br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0But if it were to work for<br> >> several projects at the same time, I suppose I could say it doesn&= #39;t<br> >> belong to any particular one.<br> > In that case I think a kind of "project reference counter" s= hould ensure<br> > that the server is only then killed when the last project using it is<= br> > killed (and the right user options are set).<br> <br> I suppose. But that kind of arrangement would require a project-specific <b= r> hook.<br> </blockquote></div><div><br></div><div>There isn't any one-to-many corr= espondence between LSP servers <br></div><div>and projects. I don't env= ision adding that to Eglot anytime soon: it seems</div><div>completely usel= ess. So what problem are you even solving with this</div><div>"referen= ce counter" talk?<br></div><div><br></div><div>Jo=C3=A3o<br></div></di= v> --00000000000031db9105ec2a6f33--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:04:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 07:04:05 2022 Received: from localhost ([127.0.0.1]:35033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oojdF-0003Pv-7F for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:04:05 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:56182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1oojdD-0003PP-Fr for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:04:04 -0400 Received: by mail-wm1-f54.google.com with SMTP id t4so4535999wmj.5 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 04:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding: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=KAp6Kqn3wzzCzGQdD8fPEm3LloIRZyT69+14aav0k9w=; b=pZIpEaWRotFS3Nk4MF/sBdRvc+3QII/qPtiGS1MObGfISP/xs1y52mK+3Wb9fy1Vvf KsiiiweOdhc8BRa1w7HhSdEFby//9ZeD5owCwdiA3Fcm2NxdX2Cyd1EBlpuao6n73OSO pw0EfiqBKmAwtJebYlUPVKymdYFyQlD2Q0ydfp155cN0oBtknXesB19rZBVnTLEyggfL KWJWw1azUGTJB3/fUfc584LGc2Lj3+Ds8EHY8NVJooqIWVa3swAQk3AJLtMslJs3hYD7 PkerCVwuqEn6OEj0w57oBchDP/0Zd7jA/u5+YdPwMCJ1S1lX8xWBAevJQ/HDzHTwXA+M qXCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=KAp6Kqn3wzzCzGQdD8fPEm3LloIRZyT69+14aav0k9w=; b=Aq6tVxi96tpi73/tTvLTACyLHSxqYkiH++bUfBusdOuyGpcp/V7UGf7ysXK+vuOTXv KEq906wAcm3361vsRow7pR0XkzKc5IQXOziFATU52RmBgDxpvfEaSb88lBFKoWhci+VC 3UOcgYxRTlv2tiwZqZTKh7QnWvr4ZO71h0hWpdlwWLDawfTFLwKzoBKCYmFfBerNx8So QyUXn1DRWJ0tswI6Xs2V0hqxHOaLb+EbHL4iCoaHjGafonaVG02ctUo9MJh89ED9SFxj P/mqkuUwq8alMYPUj0OnISvS4lzd9x9G4y12F0cVgjTCNcuXZcKXGaR+BHR9AtPjVvsS JQuA== X-Gm-Message-State: ACrzQf0AywuZ/CnmnGE55UsiAmHP5San5qQBFE/rcPrMYYDMiAir8JPZ 5mDQUpj+CFEyn74L2G6XzvU= X-Google-Smtp-Source: AMsMyM5aqXr6GxRthvrdaP+WX22GE+f5e6VSOAXpQmDpgY19XI+48j3WNDdUCOCb3jzBL8f4FsiHUg== X-Received: by 2002:a1c:f70f:0:b0:3cf:620f:fc4c with SMTP id v15-20020a1cf70f000000b003cf620ffc4cmr2155891wmh.168.1667041437637; Sat, 29 Oct 2022 04:03:57 -0700 (PDT) Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89]) by smtp.gmail.com with ESMTPSA id m17-20020a5d56d1000000b0022cc6b8df5esm1266704wrw.7.2022.10.29.04.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Oct 2022 04:03:57 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Philip Kaludercic <philipk@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <87czab16em.fsf@HIDDEN> (Philip Kaludercic's message of "Sat, 29 Oct 2022 06:38:09 +0000") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87czab16em.fsf@HIDDEN> Date: Sat, 29 Oct 2022 12:05:07 +0100 Message-ID: <87mt9ex53w.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Philip Kaludercic <philipk@HIDDEN> writes: > This is my perspective too. I am under the impression that Jo=C3=A3o or > looking at this from a too technical perspective, and is missing the way > users perceive the situation. You're not reading what I am writing. Here's a summary again: 1. buffer is implementation detail. Users don't see it any more than they see values of internal global variables. In fact I think lsp-mode, perfectly legitimately, uses (or used to use) a process, but doesn't make use of its buffer at all. It uses a special filter that processes and stores strings in global variables. These variables also "service a project" and occupy resources but I doubt project.el has a claim to their ownership. jsonrpc.el use buffers internally, just because that was deemed more convenient and efficient for parsing. 2. Users like you who are interested in controlling the RAM and CPU resources taken by the running a LSP server, even when Emacs is not visiting any files in a project should use the variable eglot-autoshutdown. This variable is exactly what you want. There is no other "user perception" here that I have been made aware of. 3. Even if we were to neglect point 1, as you seem to be, fixing things with kill-buffer-query-functions duplicates programming logic, which is very bad. And most important of all, there's no place to put the reference to kill-buffer-query-functions short of many lines completely throwing away encapsulation and unique resource ownership. If this is too technical, then I'm sorry: this is a technical mailing list. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 10:59:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 06:59:39 2022 Received: from localhost ([127.0.0.1]:35024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oojYw-0003H1-PL for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 06:59:39 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:33494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1oojYq-0003Gj-Gi for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 06:59:37 -0400 Received: by mail-wr1-f52.google.com with SMTP id h9so9643231wrt.0 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 03:59:32 -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=/R/FHV07JsHzibV0Il62r5tQF/BapS20vM5OprGQMRw=; b=O9fbn74Ej0vYgb9em3VWoinHj/CmviesJsLXk6IWr8Qg6pABRv8lS51Mwo2blYzhOV iV3EqJ87X1H/dEQwoGp2B+AKDpfbchcLq1Pl1jrAHKedSb8u69uQE59rPkKXrGBzfUfE nq6qHj8RVPlQwAK6w0otjKpvJCNr+3xo97uepLaMukChNj585jc0B63NMis8auWyVCrl JXqKWOY5zcIAV1L4kXUnVn+wkHM6annL+oE3/GXWUh5F3CRNdu3iG68Kf7LZjNy5VCX9 WDHGZo51LnSIG/L3Y0o0dEUozPWq/kKZtalTVSnkmO98bXSDBPYLcX6AIZBPqnaJUl1t U1Gw== 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=/R/FHV07JsHzibV0Il62r5tQF/BapS20vM5OprGQMRw=; b=g683nAx2O4fgllZ2IyrMaCnOf8lN8V7FJG41kK5M2Uujvkl8O2l6VfVfK0d5L9unRy TQKzMII9Htzqmb3El0DEFw35+qGarAKIgevcyq1PZfpILI0uMzrYFOa6+Bc9W6/PHNoE jaEs9dN8eI8fZ0Y2soSPtfGicHqtMEf2smdiCTjJuFci9ZxgIkuLv1NLwYFeTEuXyhsi hKuHatrxkNJ9N4ANIBs8Sqy3KXqUtEFytg3Mh4Qf+v9L8L9Kfp+m30O9B+7w6D/6XctL 2ULNvczhEpntaw31fxjIVmHIaAijzFPSHNXxA5tx6Ioo3oWLakqBvB6YU46vQlWOzjtG CyXQ== X-Gm-Message-State: ACrzQf0BV4bEJjaftuf1UNZGyIlgOIBkRGywH8of/fFq6uOaIfoyOVYZ kSc6BLi/SCQR8zxX2+xCnM8= X-Google-Smtp-Source: AMsMyM4DveLiLIOfH4LfEY5cWSlpO35A8itpZRXEA3fDnaTh9KtheqdDB48A6AMe/+EI7jY2NlD6mw== X-Received: by 2002:adf:d089:0:b0:236:558b:abc8 with SMTP id y9-20020adfd089000000b00236558babc8mr2042465wrh.231.1667041166424; Sat, 29 Oct 2022 03:59:26 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u7-20020a05600c19c700b003c6c2ff7f25sm1375551wmq.15.2022.10.29.03.59.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Oct 2022 03:59:26 -0700 (PDT) Message-ID: <5ea24d00-2461-7901-86d6-6bdb01f30020@HIDDEN> Date: Sat, 29 Oct 2022 13:59:24 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87czab16em.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87czab16em.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 29.10.2022 09:38, Philip Kaludercic wrote: >> 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. > In that case I think a kind of "project reference counter" should ensure > that the server is only then killed when the last project using it is > killed (and the right user options are set). I suppose. But that kind of arrangement would require a project-specific hook.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 06:38:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 29 02:38:19 2022 Received: from localhost ([127.0.0.1]:34836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1oofU2-0002kO-VF for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 02:38:19 -0400 Received: from mout01.posteo.de ([185.67.36.65]:56339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1oofU0-0002k6-QO for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 02:38:17 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 35E6C240028 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 08:38:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667025491; bh=x0JCDjSusjc1lShQnGCFd69Y9IrqgQ1sT+L1crE4X5Y=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=pbMjb1dYGx1ZqvTeb8KMN/79qJcCxx7je74uTRUiOtjK8JPI8jz257Bjv5Th/8ETC 1YxGO26g9VmTaiSHT4TZ+gSYPRlAH2gjmcmidbJGLaPOuxkMaL9Mf5/ZUptM5wchvo TlIb/Qudn09t9ukkf0t7jW8m3Aax94psRmnqWs0aOuiUyymD/BoaANJmzG0ttltzuo QfV1aAVBE/WXpfVkSsrgP5J7YOU0UBjt7KIg0FClGysOMOre+w13KItkOmF9epU7yZ a/gc5Z3gRTqsm/on2NcfJ1iktP2ijxKua3ov/7WTLViwHD4WTQuHb32/3ezyJ+Cujl NTv86O5teIfxQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MzqVV10m2z9rxQ; Sat, 29 Oct 2022 08:38:09 +0200 (CEST) From: Philip Kaludercic <philipk@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> (Dmitry Gutov's message of "Sat, 29 Oct 2022 04:09:13 +0300") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Sat, 29 Oct 2022 06:38:09 +0000 Message-ID: <87czab16em.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58839 Cc: 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Dmitry Gutov <dgutov@HIDDEN> writes: >> 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.=20 This is my perspective too. I am under the impression that Jo=C3=A3o or looking at this from a too technical perspective, and is missing the way users perceive the situation. If it is currently not possible, then this is an issue not an excuse that we should tackle. IMO having Eglot integrate with project.el ought to be fine, since project is an Eglot dependency. > 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. In that case I think a kind of "project reference counter" should ensure that the server is only then killed when the last project using it is killed (and the right user options are set). (Btw., the tone of this discussion is a bit unpleasant, could we try and focus on the issue at hand and do our best to understand each other?)
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 01:38:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 21:38:34 2022 Received: from localhost ([127.0.0.1]:34625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooany-0001BA-4o for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:38:34 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:44701) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1ooanv-0001Aw-3f for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:38:33 -0400 Received: by mail-wm1-f45.google.com with SMTP id bg9-20020a05600c3c8900b003bf249616b0so4881209wmb.3 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 18:38:31 -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=T1/g2QpkiYxmE9EqeXM0SBU9TGqsuE6ECzZds2++sfY=; b=b+QhHQOY/f48MKpm2ZiyPIQrCIxloMkfE6+CIuBxHcYC0Hv8jQGg8aYpgkHkLeuGU4 HfSWvYhV4LYejdWTb5/8G1QmAn34OKpA54mLHzdUqVCUAmx0FcymiEdnGRuzqURe2afo q4ZmQs14qr/e7rTN+9cmgM7GSEaPjski8BXvdwRscL9j4JbliLn7uWKp8rz6bFAYuyE8 lAdiURaHJgxBk4khUNcImnREbCEWa9FkUrKdQgPrRzxoW76lvGmBSrfKA8vvTma5xvUt fFpSVTkIMZ/n1JISbwWOoKBS/lMzmJZ1pv081FtRP+Fk6tgTfK0TuKWxtW/nQkeHv6Xg Aj0A== 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=T1/g2QpkiYxmE9EqeXM0SBU9TGqsuE6ECzZds2++sfY=; b=3/+uWYUzDHrBcISAkM6rhdLlpvlbVFewsdZZ8dfrh1fjLapPehcG1e0MkoTRoz30mc Yhs5FNyrtooBIoqUMi9dQoFLMAaLmgWwQGQzu+FV35b5XQLjUuTWaZfiQ/WevrPfhDrt 5RC2DQeXbfERQ5MbBFzCCAG+88F6DirxmRF1ox54guvASxsej6slTwZjMI4yaFb1zJ13 Dhu+WVSp8wuW3Ob4pkrcX0mKdSRJmY1pQZ8xkpCtL21fTap+XZEq09EPch6mZ1vhKnep FaJLmd15RZDDCpBz81gO4+20Mjs2lzvqNofe8OR8LuPvB1CtifBCeWLCO6oSGQjjxZhL cWsg== X-Gm-Message-State: ACrzQf3ve6UoofZZeJmpuSji+MIqWjdb1OsGQDpc53uRxx6w7/WjbZ4c BtwKvq564NE0AiTTSzCKT2Q= X-Google-Smtp-Source: AMsMyM5kWPnEuBEAVYQn8DL1vDDAG2O2fsTgjBk+/jcAGa2YfJ1Hvk3DftFysnc6uk0nMuvEE9NNjw== X-Received: by 2002:a05:600c:314f:b0:3c6:f27d:fa52 with SMTP id h15-20020a05600c314f00b003c6f27dfa52mr11087713wmo.20.1667007504982; Fri, 28 Oct 2022 18:38:24 -0700 (PDT) Received: from krug ([87.196.74.89]) by smtp.gmail.com with ESMTPSA id m13-20020adffe4d000000b0022afcc11f65sm172855wrs.47.2022.10.28.18.38.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Oct 2022 18:38:24 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> (Dmitry Gutov's message of "Sat, 29 Oct 2022 04:09:13 +0300") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> Date: Sat, 29 Oct 2022 02:39:34 +0100 Message-ID: <87v8o3wgq1.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > Sorry, I don't have Eglot checked out, or the time to test out the > patch. 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 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. >> 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. >> 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. >> * 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?? 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
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 01:09:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 21:09:23 2022 Received: from localhost ([127.0.0.1]:34585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooaLi-0000S0-Tt for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:09:23 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:33352) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1ooaLh-0000Rm-2q for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:09:22 -0400 Received: by mail-wm1-f48.google.com with SMTP id 14-20020a05600c228e00b003cf4eaef74eso4140489wmf.0 for <58839 <at> 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) 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) Message-ID: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> Date: Sat, 29 Oct 2022 04:09:13 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87zgdfwkle.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 29.10.2022 03:15, João Távora wrote: > Dmitry Gutov <dgutov@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 00:15:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 20:15:01 2022
Received: from localhost ([127.0.0.1]:34523 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ooZV6-0007UK-Qx
for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 20:15:01 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:33493)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1ooZV1-0007Tx-0Z
for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 20:14:59 -0400
Received: by mail-wm1-f54.google.com with SMTP id
14-20020a05600c228e00b003cf4eaef74eso4119896wmf.0
for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 17:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=content-transfer-encoding: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=HMjLyUQUBWPWXEFvLdG+3+qjKdrBmYkWm4ht3LFRSGk=;
b=bow9NPHVhq+2xCikKWo9PKl5e3Ca1u7susqaXZZt/MblT1Dw4uCfmSt28XCriWYM1N
aMK8bveqq97Ea1dIN4YrlV9aeVTOpyNJBm5H+0m3DtF0Vru+uyrd+KG8L8Ddp0RHfzbj
49PdpCIr2asKkRbr5zQ4eAO/0bYt2FRlg+b5r04BuCkV+675/+5P0UHXurW4sGFbJxU1
94OQdlwbfooGzM1/3rVmEuL9Jo5pFGEaOwWlpvR1+65yvQbsU4hX8ax768nkxI3LfTQc
T3nUEVqYT/aRKVyds0P5M99h8K3iiBHy7l48xjxmTSI0PYZf/2E/xPOft/Pk1PDnCySB
pwXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding: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=HMjLyUQUBWPWXEFvLdG+3+qjKdrBmYkWm4ht3LFRSGk=;
b=1caPViiGu8mVZhlhjJQxOfYQbJC7rQeYiFskZtZz7RRXxU9WP9ss1QEK1f9becYAZ0
nm1GNEdjEEaAMoamX8vRFSrSgaXjZOhgBq8fWm+yHukHD2NjdDsbkJZOHQ0y9GAqMD1G
IukwPWxyPy77UXEq2r1i/u7i2/0rH352/QNPMv633ljg2uEmfKmMWNGI0QVjmgTvN8Kf
2pYgEsbrsvQ/49mfWrTgb6c6f+RW8CXYZu5UGqiEUn7dUmB0wlvEOSxgs7uHk9NgsUB+
yhbQ5Rl2sIjhDjWgY0Etc1M6ji0+HPtVzLxFeLfHlGyxxpT951j9dc4uHwgzLPSe/kM+
i1iw==
X-Gm-Message-State: ACrzQf0GODL6tCIGQUOSPqbWe2sPV/mTy+HmJpTmQNm8Vzuh9JEK4Gjx
K5Rq17GhH0/CKbO0BzkBI4Ww0stywH4=
X-Google-Smtp-Source: AMsMyM5duHoYlo9KHiORI+4lg8bppNrVl64uKzg1x9X8qPfUG0OExG++13HlI9OU6YW/lZKViNy4WA==
X-Received: by 2002:a05:600c:600e:b0:3c6:fc59:5eda with SMTP id
az14-20020a05600c600e00b003c6fc595edamr1020521wmb.30.1667002488607;
Fri, 28 Oct 2022 17:14:48 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
by smtp.gmail.com with ESMTPSA id
s12-20020a5d6a8c000000b002364c77bcacsm70450wru.38.2022.10.28.17.14.47
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 28 Oct 2022 17:14:48 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer
fails when Eglot is running
In-Reply-To: <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> (Dmitry Gutov's
message of "Fri, 28 Oct 2022 21:40:58 +0300")
References: <87sfj8umwb.fsf@HIDDEN>
<CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
<87edur3lil.fsf@HIDDEN>
<aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
<87a65f3j40.fsf@HIDDEN>
<213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
Date: Sat, 29 Oct 2022 01:15:57 +0100
Message-ID: <87zgdfwkle.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org,
Manuel Uberti <manuel.uberti@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Dmitry Gutov <dgutov@HIDDEN> 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.
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? 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.
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.
* 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.
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.
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.
Jo=C3=A3o
diff --git a/lisp/jsonrpc.el b/lisp/jsonrpc.el
index 90833e1c1d..2914d380e9 100644
--- a/lisp/jsonrpc.el
+++ b/lisp/jsonrpc.el
@@ -365,6 +365,9 @@ jsonrpc-process-connection
:ON-SHUTDOWN (optional), a function of one argument, the
connection object, called when the process dies.")
=20
+(define-derived-mode jsonrpc--fundamental-mode fundamental-mode ""
+ "Make project.el's stay out of our internal buffers.")
+
(cl-defmethod initialize-instance ((conn jsonrpc-process-connection) slots)
(cl-call-next-method)
(cl-destructuring-bind (&key ((:process proc)) name &allow-other-keys) s=
lots
@@ -377,6 +380,7 @@ initialize-instance
;; (but maybe not a slot).
(let ((calling-buffer (current-buffer)))
(with-current-buffer (get-buffer-create (format "*%s stderr*" name))
+ (jsonrpc--fundamental-mode)
(let ((inhibit-read-only t)
(hidden-name (concat " " (buffer-name))))
(erase-buffer)
@@ -411,6 +415,7 @@ initialize-instance
(set-process-filter proc #'jsonrpc--process-filter)
(set-process-sentinel proc #'jsonrpc--process-sentinel)
(with-current-buffer (process-buffer proc)
+ (jsonrpc--fundamental-mode)
(buffer-disable-undo)
(set-marker (process-mark proc) (point-min))
(let ((inhibit-read-only t))
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:41:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 14:41:14 2022 Received: from localhost ([127.0.0.1]:34278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooUI4-0000ye-3E for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:41:14 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:44727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1ooUHy-0000xy-Nl for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:41:10 -0400 Received: by mail-wr1-f47.google.com with SMTP id v1so7701010wrt.11 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 11:41:06 -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=ljY+AsPqvYxkR7JuJNSPTaTitINx+vL34JWr9iTBxiE=; b=TiyyvASyt9GJQxtGNpho1gHkttzBTIXg9DfyguQzXUL3hCtD2H5OJ9nayUdNYCXEIS 0N+J0Ywg/l2U0+055yqpkmwcMevVOxU+jMk0118aq8ysoAIzGxWT0ZztNI6m7T+JyGH9 aTSFVZ73UPw11r/ziYnY4xkAcJLzAxKCGWYey7vL1TgiYkiwfXX5epkGbC1Ug3kGcat6 Zbq45JBAMrNvrKwt+okaye0O5mIViqrHU12Ns7lNAkViytyHYsg0BLhJWK0qV5+dwXhk POh1bHGjtBHxpAgAAHtN/RY8HXV0JJCk2b4jk5WNePxturwaEBvtPP3kIZbBf6Q3VbPY L6+Q== 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=ljY+AsPqvYxkR7JuJNSPTaTitINx+vL34JWr9iTBxiE=; b=0GK6XpopSG4A4twjkPTlh98ydd+2Ia+kHtI9+Ah6MrqaSKFMmN10/kebl8IkzeJKSO vuqD8Ic6IBbIlR+CyqwNE1VbJs7d/cBsDz2NCQPoyqkjDMh9WTJklLDNh62D3PzWhx8V zosrma5k8tkqhOSoWy9kxWJZLZitcH79Uv2bRRiepCycKVWDM1YBd6qnZwzGh21SxaRp yfyV4XkwdG8w4cdbkmPkl2lIkhqs7p6OlDPpsm9s8SSthl7H0dRR8iyvEMU9mjv3+fHa QzhIP6yZrYnbHjgmrT7b4a8aJP1asUYNVpmWAa6EWw+7X7F9wVACTtNNyV/6YvU5Gmi9 OzXQ== X-Gm-Message-State: ACrzQf2h62IUB2LgyGyHnnJRfF4nYtndKl4zC7iKxs24N2R43wNzKG7G tIDoqLiFdVLY11W2Y5D63Vs= X-Google-Smtp-Source: AMsMyM4mXGPwOUW4AO2m3RJVj88LZYIj5y5IL/L7rdyeG3h6FNmJoWvn/pY6gJUSZSaXeOsC4IDHdQ== X-Received: by 2002:adf:f883:0:b0:236:a6a3:d6ac with SMTP id u3-20020adff883000000b00236a6a3d6acmr448698wrp.538.1666982460731; Fri, 28 Oct 2022 11:41:00 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t14-20020a5d690e000000b00225307f43fbsm4034921wru.44.2022.10.28.11.40.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 11:41:00 -0700 (PDT) Message-ID: <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> Date: Fri, 28 Oct 2022 21:40:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87a65f3j40.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 28.10.2022 21:20, Philip Kaludercic wrote: > Dmitry Gutov<dgutov@HIDDEN> writes: > >> On 28.10.2022 20:28, Philip Kaludercic wrote: >>> I still don't agree that this is the right interpretation of the issue >>> or solution, but wouldn't it be better to add this to >>> `project-kill-buffer-conditions'? >> I don't mind a new variable specifically, but >> kill-buffer-query-functions seems to serve this purpose just fine. >> >> And no extra "coupling between two packages" will be added. > How would you imagine it being used in this case? (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. In either case, it will also cover the scenario of the user killing the background buffer some other way.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:31:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 14:31:19 2022 Received: from localhost ([127.0.0.1]:34274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooU8U-0000kD-Tu for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:31:19 -0400 Received: from mail-oa1-f53.google.com ([209.85.160.53]:46048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1ooU8S-0000k0-7y for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:31:18 -0400 Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-13be3ef361dso7178140fac.12 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 11:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dsdCkw3+Y9upUNKOyKq4YiYwt11xbrecoFyaugno7fg=; b=TS1hxPnHEaPsBD+uWTEbCv+EVYcbzbUUYIXjva+elxuX03ELMXZPOJ/k0qAsk8FIm/ tQx67BDo9qEZf8OerQTRZMcYrBRe+Vd9n3xkVjWIrEECy+LzquHmc4BVPZbZUXWMKMi9 vzjzHnh15Rj/HPQRqu1xWnhvjSLkm+AidYB0DFbQQXFcfzi58j3R5kWx9DUfbODpu5fL V1hQ1vaZ6JB/GYRHqRPsoyMPf2hhYxguQqf3WkskWeuFtzNoMKu1GDc/IM9B9ciOF96e xN6fqzLArTepFs0SJAGR5f7qcSZ6AY+Z8OPQV4UVnQ+ANTOMAOCcSRuE57/SwG2KOG34 RrjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dsdCkw3+Y9upUNKOyKq4YiYwt11xbrecoFyaugno7fg=; b=6J8IYdy6t9h5puWL3s5Y53KXaFZr9Waq/Zk3/2TtwQGUtRCdCTrdlWVW7NHmjp3nOG qs1+VZ6wDTsNnt/F9BzzCO5YKydCsgDf4NBKryavxkUpFcJS/vmU/lGvpmlRHmBtRKlq I/QljsRjyrxMkQpvCd6XDcy4D+I0jgHxAQgLjNGtr0VsfMfYMz9zE5f9SO6JHgYcYzcE 7d8iWythc0uD2b4tJq0e7qidF8uH+T4dQyBCwdcBSLpZHbx125JWbwDEt2q96k5Ii+a/ BXNojsMEd1VpvgalXUkgl154mz6NOKo6/B5vWzOk4u2lwymAYr/TdlC89wnBvijvpVj3 ReOQ== X-Gm-Message-State: ACrzQf1Bb9mlRu18k/uqp3slOPJb1cIYt1n6wq8PHiQwpGD2KOZhcIJ2 HEOOrCaPLdhCEqevoR0jIGFIQ+d5XXTvtcSzik4= X-Google-Smtp-Source: AMsMyM77PZzRRms58T/8T0GoU1C/QWSN2cYjtbCV9RbbRpJ8GWK/M80SH4AEWiY4CCsx6Q/Q82/PNG44LhWOL+AZxRA= X-Received: by 2002:a05:6870:2155:b0:13c:8db1:2446 with SMTP id g21-20020a056870215500b0013c8db12446mr1524113oae.171.1666981870623; Fri, 28 Oct 2022 11:31:10 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN> In-Reply-To: <87a65f3j40.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 28 Oct 2022 19:30:59 +0100 Message-ID: <CALDnm50uCekkuvzM_WB1cQ3Gp1tbRZaPXP=c-Pt=y-vUhj2JWw@HIDDEN> Subject: Re: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000003ee50d05ec1c76a6" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000003ee50d05ec1c76a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2022, 19:20 Philip Kaludercic <philipk@HIDDEN> wrote: > Dmitry Gutov <dgutov@HIDDEN> writes: > > > On 28.10.2022 20:28, Philip Kaludercic wrote: > >> I still don't agree that this is the right interpretation of the issue > >> or solution, but wouldn't it be better to add this to > >> `project-kill-buffer-conditions'? > > > > I don't mind a new variable specifically, but > > kill-buffer-query-functions seems to serve this purpose just fine. > > > > And no extra "coupling between two packages" will be added. > > How would you imagine it being used in this case? May I suggest that we jump over the imagination directly to the reality? The patch provided lives in the latter realm. Jo=C3=A3o > --0000000000003ee50d05ec1c76a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>On Fri, Oct 28, 2022, 19:20 Philip Kaludercic <<a= href=3D"mailto:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></= div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex">Dmitry Gutov <<a href=3D"mailto:dgutov@HIDDEN" targ= et=3D"_blank" rel=3D"noreferrer">dgutov@HIDDEN</a>> writes:<br> <br> > On 28.10.2022 20:28, Philip Kaludercic wrote:<br> >> I still don't agree that this is the right interpretation of t= he issue<br> >> or solution, but wouldn't it be better to add this to<br> >> `project-kill-buffer-conditions'?<br> ><br> > I don't mind a new variable specifically, but<br> > kill-buffer-query-functions seems to serve this purpose just fine.<br> ><br> > And no extra "coupling between two packages" will be added.<= br> <br> How would you imagine it being used in this case?=C2=A0</blockquote></div><= /div><div dir=3D"auto"><br></div><div dir=3D"auto"><div dir=3D"auto">May I = suggest that we jump over the imagination directly to the reality?=C2=A0</d= iv><div dir=3D"auto"><br></div><div dir=3D"auto">The patch provided lives i= n the latter realm.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Jo= =C3=A3o</div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class= =3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> </blockquote></div></div></div> --0000000000003ee50d05ec1c76a6--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:21:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 14:21:04 2022 Received: from localhost ([127.0.0.1]:34252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooTya-0000Sx-Dm for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:21:04 -0400 Received: from mout01.posteo.de ([185.67.36.65]:40737) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1ooTyU-0000S4-Nc for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:21:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 8DE0A240027 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 20:20:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666981252; bh=xHzjSbUD8YcF5nDe2B3QfuX43RRLVXCw7u+bPXzDCUQ=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=TMzfRsB/YntCXZjMnSma/lR20crUDyq+qWho+9VhlhuDZiQTGF4ITgffh3rW8p9zv AEokmhZXGye5vtQYWyIdijZP4dCrl/K2F4nOwOlqkAuZUJMTMYwXZvmp4R44jUCzxx e4gDe4OxMX03EXb5ZKeV6UlSKQh5HVz3Gr9g8hWRHiIWZwDOXb8kZXS8KM6Xu0o2EW TQtc84mtHBTtNPk7a4Eqpi/TOiLErajC6Lgdia3S2oTZURtOCPLsRp4FkUXDWgjxG7 Q6C+G6uJyY2r8uID+7Y9ZKLnMLBXFIjvQXOim+2Z0L0R4b63ihOa4UayVmLfji+DPG ZRzFZtUNlj8XA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MzW7k57Zfz6tmM; Fri, 28 Oct 2022 20:20:48 +0200 (CEST) From: Philip Kaludercic <philipk@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> (Dmitry Gutov's message of "Fri, 28 Oct 2022 21:14:25 +0300") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Fri, 28 Oct 2022 18:20:47 +0000 Message-ID: <87a65f3j40.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Dmitry Gutov <dgutov@HIDDEN> writes: > On 28.10.2022 20:28, Philip Kaludercic wrote: >> I still don't agree that this is the right interpretation of the issue >> or solution, but wouldn't it be better to add this to >> `project-kill-buffer-conditions'? > > I don't mind a new variable specifically, but > kill-buffer-query-functions seems to serve this purpose just fine. > > And no extra "coupling between two packages" will be added. How would you imagine it being used in this case?
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:14:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 14:14:38 2022 Received: from localhost ([127.0.0.1]:34240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooTsM-0000IZ-0O for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:14:38 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:44725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1ooTsH-0000IH-54 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:14:36 -0400 Received: by mail-wr1-f41.google.com with SMTP id v1so7626598wrt.11 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 11:14:33 -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=RoZdUhsriRrC/v6F7u2dkDpRLeu8GwlgG3iWKgtJjbQ=; b=CNO0+d8LOTx/j5h+3BdSKeBUIsEDhdz1amh72vlXe8eyJJ2asdA0NdXW8GGZOGCWuL gb6HaN/Fx740r/uJaEtONjsXByhHP7+u0mK/tgjK+61+l+8qki/FwqWVvrPg0SyC0YBx QuPvgRXK8k8on4CrEy/kx7/guBHOsG6RUPSzOX/ItnNgdb9py+1Iiv+A+5MV7T1RdEMs 155ehbTgg3xtVZSOlyQXI68MSpB6zQ+eyxKaCHs+VKtVDsPFCBPu8IXC2kpwiRZdQ1W9 uFrB9lecOWBOhWGMLNqAJE6O37MIK4BoCkGdYMnckGSGlpXk1lXiu/LBK0GJjUQmdoc/ 8MAw== 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=RoZdUhsriRrC/v6F7u2dkDpRLeu8GwlgG3iWKgtJjbQ=; b=dlEGzUKQeUw13tvGAQs86YBXVCB9IaF8u3lEfnx1fn+BNUndy0NVvoiT7JV9vWtkPC 3UAgymZa9KRuHnvrxRmlcqplQOkzQJxRY3W0qf3gXxDgPCUimWvoF2w6B/UYL+uGAGBP 2wLILoZjhHinxc/J+ugIWQVo4KG1PQrBPFf/imc8WSsw68plFAq6DQohzJpFu+WuaKps xvIuQ3J8H/m/aEmi0/rwmcDp5p6Ca+y8FsqvUfjXKKwsHXFoE1V35qnM0FH7fj1TEEmU MlW4+fFmJ5Sy8MmVQQ9I/2ob/X8cE50XsBf+oh7eTUmoIuZ7MgkOJFlL39ZU+bWDSM2s g1TQ== X-Gm-Message-State: ACrzQf368SGb95/MdXhgFIjqeF7Flje7WbpbbYQJ0B1MQiJjK9fv8sJX kuU8EeAKKWSCF8AflmkfmwBdIpxH/wU= X-Google-Smtp-Source: AMsMyM4OEdcA0EgEO/GLlDHKue+cD9SXuxScyExJPZg2HyMGE0zjbadhM72vIWFC0CiLIlD0zi4eLw== X-Received: by 2002:a5d:4e8c:0:b0:236:6f5a:e893 with SMTP id e12-20020a5d4e8c000000b002366f5ae893mr397568wru.44.1666980867561; Fri, 28 Oct 2022 11:14:27 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id bt6-20020a056000080600b0023677e1157fsm4406855wrb.56.2022.10.28.11.14.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 11:14:27 -0700 (PDT) Message-ID: <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> Date: Fri, 28 Oct 2022 21:14:25 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Content-Language: en-US To: Philip Kaludercic <philipk@HIDDEN>, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> In-Reply-To: <87edur3lil.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) On 28.10.2022 20:28, Philip Kaludercic wrote: > I still don't agree that this is the right interpretation of the issue > or solution, but wouldn't it be better to add this to > `project-kill-buffer-conditions'? I don't mind a new variable specifically, but kill-buffer-query-functions seems to serve this purpose just fine. And no extra "coupling between two packages" will be added.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 17:35:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 13:35:56 2022 Received: from localhost ([127.0.0.1]:34206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooTGu-0007lv-7e for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:35:56 -0400 Received: from mail-oa1-f42.google.com ([209.85.160.42]:34733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1ooTGs-0007lh-BO for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:35:54 -0400 Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-13ba86b5ac0so7082869fac.1 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 10:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=feoRXod2uxVIgJD8Xr8N0mIda1WYvWiIoq7xhULSrxk=; b=Y0miWxW8LgurcD8Aw15lTERHdZJ4sfSpJ47bn+lUTGIvOSklTX0V6oSFm/8i+l1gjz odQ4hfhtWARLx3XdqzPy+vfhjxAypprQPCTedeW0pfpCRhx2hqkkbGOVcfQFMBLdXzge uK8meA0CAU7MlWigfjXK64zW9OwoNUezgUz0L30MahJSVPhkRIFUO/FOuMQejpaxPpVW dZ9U2Xao0Ap7rC8qYgBEgyskMEFK34vMuF5S0/a0/s4RXodE/4mRiMIga8QLVgM7tTIZ y2CSNa+lUoSmc64sa5PItOC5nLx4rrzWBG5TAzPV2VjHe4u+wSmih4X3w0hdQplJPUxo xnsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=feoRXod2uxVIgJD8Xr8N0mIda1WYvWiIoq7xhULSrxk=; b=K8mcuZX6j5u/6Kx4Ipag+4l2jeQkkqxG5lKqXGqCjYcSkM0jsD13TgszQrY0Io5TCu scVjBD+8QUrsjuDXxPBlcvzxtb/DIlwp+ekiS0eH/FzovT6LArmVkRlLU7ziaY99H9sd nIzwgsBV5IaKP3dmBhAVAGysJKuGslBgF5b6c0vHEZmS0DtSslUU80UglnuyQOIqS0Fp 1ZPXAJT/CfdAVA/lcZwOCuYbJBD78NzaZ51EvQoF8Q9ZUc7O26gIWUdH0piZapkP/EhA IpThkRGWRhY0pYav1h6PikQJ8NVFyqgqFQFLD4JKLpoH6yDMO1a6YtmFWJelPyztgCq1 gtpQ== X-Gm-Message-State: ACrzQf2CseAyT77BQrZxhr2qwKganPHY0DcE/eKgN/7P2Y/Le0nGUAZs 5edOv98imEQ1iu/qNXP6teHe9ELgdrGOKTxXn9A= X-Google-Smtp-Source: AMsMyM7HdMZb8rrqCrQbtItf0zZLzSXLM0qWhzkVnzLPDb/GiLfL71rFQdDgU7tc9CDJw1po8kiOYNH2d0uRcDzGy8w= X-Received: by 2002:a05:6870:2155:b0:13c:8db1:2446 with SMTP id g21-20020a056870215500b0013c8db12446mr1393909oae.171.1666978548597; Fri, 28 Oct 2022 10:35:48 -0700 (PDT) MIME-Version: 1.0 References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> <87edur3lil.fsf@HIDDEN> In-Reply-To: <87edur3lil.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 28 Oct 2022 18:36:48 +0100 Message-ID: <CALDnm51t_G39W6s1VVbtE7qjsAdeh1+bxLuQNk=entsaV-O-rg@HIDDEN> Subject: Re: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running To: Philip Kaludercic <philipk@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000003cc74405ec1bb08d" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --0000000000003cc74405ec1bb08d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2022 at 6:28 PM Philip Kaludercic <philipk@HIDDEN> wrote: > > I still don't agree that this is the right interpretation of the issue > or solution, but wouldn't it be better to add this to > `project-kill-buffer-conditions'? > > The solution I would prefer is if project.el would define a sort of > project-kill-hook, that Eglot would modify and make sure that > `eglot-shutdown' is invoked before any buffer is killed. > I believe we have been over this. Eglot's preference eglot-autoshutdown and eglot-autoreconnect already control this behaviour. You should use those: eglot-autoshutdown does _exactly_ what you want: shut the process down (in a controlled fashion) if all manged buffers are killed. You may argue (in a separate issue) that eglot-autoshutdown's default shoul= d be t. Just like any other user preference, we can weigh the pros and cons. That buffer is Eglot's property, just like internal symbols or global data structures. Just because it's a buffer, it doesn't mean you may touch it. It is hidden because you may not. What would even be the advantage here? You can of course show a patch, but I doubt it's going to be much simpler than what I have proposed. For starters, your idea increases coupling between two packages, which is generally not good. Jo=C3=A3o --0000000000003cc74405ec1bb08d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Fri, Oct 28, 2022 at 6:28 PM Philip Kaludercic <<a href=3D"mai= lto:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex"><br> I still don't agree that this is the right interpretation of the issue<= br> or solution, but wouldn't it be better to add this to<br> `project-kill-buffer-conditions'?<br> <br> The solution I would prefer is if project.el would define a sort of<br> project-kill-hook, that Eglot would modify and make sure that<br> `eglot-shutdown' is invoked before any buffer is killed.<br> </blockquote></div><div><br></div><div>I believe we have been over this.=C2= =A0 Eglot's preference eglot-autoshutdown</div><div>and eglot-autorecon= nect already control this behaviour.=C2=A0 You should use <br></div><div>th= ose: eglot-autoshutdown does _exactly_ what you want: shut the process</div= ><div>down (in a controlled fashion) if all manged buffers are killed.</div= ><div><br></div><div>You may argue (in a separate issue) that eglot-autoshu= tdown's default should</div><div>be t.=C2=A0 Just like any other user p= reference, we can weigh the pros and cons.<br></div><div><br></div><div>Tha= t buffer is Eglot's property, just like internal symbols or global data= structures.<br></div><div>Just because it's a buffer, it doesn't m= ean you may touch it.=C2=A0=C2=A0 It is hidden because <br></div><div>you m= ay not.=C2=A0 What would even be the advantage here?</div><div><br></div><d= iv>You can of course show a patch, but I doubt it's going to be much si= mpler than <br></div><div>what I have proposed.=C2=A0 For starters, your id= ea increases coupling between <br></div><div>two packages, which is general= ly not good.<br></div><div><br></div><div>Jo=C3=A3o<br></div></div> --0000000000003cc74405ec1bb08d--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 17:29:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 13:29:08 2022 Received: from localhost ([127.0.0.1]:34200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooTAG-0007af-QV for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:29:08 -0400 Received: from mout01.posteo.de ([185.67.36.65]:60963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1ooTAB-0007a0-4k for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:29:03 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1C277240027 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 19:28:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666978133; bh=2Fc7mD3YcDQlwbpPR5bzCJSYdApFd+rcVmgZi5q4PYw=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=gXbzDwqz0kgWV5TbY9uPoUSN4h/Gtmj0rna/LgzE2JNZ5lymMsFh1gPlepArTTBEO nIhLKhclULvLb2G4y6UuO6rdRH6+uzYYIuASNX07oqieAuDeSBW5WwLP+ZU6AKLgoE f5EIqgwK/BwnC3JzjsJIQEeXO9tvf1zm+MVGz/krDDxCyW+2faJcDWtogHTwUWmZjo Ho3LFMdCEHoT2394+0UIYwfvfcuA/k3W9Z8UTuClGlHMnLeBS3ROZHMhD6Hv0rM2Mq yiveJOZAHxM4qMawYej8o+qmZDIuM2/THoglwbgOM1ra5XHV5CzRjkCkqJMybz1E7B yOps+voJ4NaCg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MzTzm1r66z6tmX; Fri, 28 Oct 2022 19:28:50 +0200 (CEST) From: Philip Kaludercic <philipk@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running In-Reply-To: <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 28 Oct 2022 18:17:18 +0100") References: <87sfj8umwb.fsf@HIDDEN> <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN> Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Fri, 28 Oct 2022 17:28:50 +0000 Message-ID: <87edur3lil.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58839 Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic <philipk@HIDDEN> > wrote: > >> When wanting to clean up behind a project I like to use C-x p k to get >> rid of everything I have opened related to it. If I was using Eglot and >> there is still an active LSP server running in the background, killing >> the project fails with these messages: > > Thanks Philip. This was discussed at > > https://github.com/joaotavora/eglot/discussions/822 > > Some more information is needed: > > 1. The error only happens when eglot-autoshutdown has been set to t by > the user. > > 2. When it has not been set to t, then the behavior is still not > correct, but the user may not notice it. > > 3. According to Manuel Uberti, the problem also happens with CIDER, a > Clojure IDE for Emacs. So it seems it is not exclusive to Eglot. > > The problem happens because `project-kill-buffers` uses project.el's > sense of a project buffer, and then endeavours to kill all such buffers. > > So far so good, but the determination of project buffers according > to `project-buffers` considers all buffers whose buffer-local default > directory starts with a given root of some project. > > This is subtly wrong because it also considers buffers whose name starts > with space and without buffer-file-names, so-called "hidden buffers" which > are deemed "uninteresting" to the user (according to the Elisp manual). > They commonly function as implementation details of other packages, such > as Eglot (and possibly CIDER). These buffers are not normally visible > to the user in M-x ibuffer, switch-to-buffer, etc. > > In Eglot's case, the buffer whose name is " EGLOT process..." is > created by eglot.el and then handed over to jsonrpc.el, which becomes > responsible for it. > > Killing this buffer from Lisp using `kill-buffer` is incorrect because > it contradicts Eglot's user preferences eglot-autoreconnect and > eglot-autoshutdown: > > 1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the > process and confuses the LSP shutdown logic, which is a polite > "teardown" conversation with the LSP server. This is Philip's error. > 2. If eglot-autoshutdown is nil but eglot-autoreconnect is non-nil (in > fact, these are the defaults), killing the buffer has the effect of > immediately restarting the connection, and thus re-creating the > buffer. The best that can happen is that nothing was achieved > and only time was wasted. > > The fact is that the buffer in question is an internal Eglot implementati= on > detail that other packages should stay clear of. > > In fact, I think that all hidden buffers can be considered thusly. > They're just like `--` symbols in obarray or in other symbol's plists: > they're visible to all Lisp packages but they are implementation details > that shouldn't be messed with except by the owner of such details. > > Dmitry tells me that there was some discussion where it was determined > that it's somehow useful in project-kill-buffers to also target buffers > that the > user isn't aware of. > > But I've not seen evidence of this usefulness. If there is indeed some, > I propose we come up with some convention so that it is possible for > packages to create buffers which are "definitely hidden and private and > not to me tinkered with". Such a convention could be starting the > buffer name with two spaces. > > Whatever the convention, currently I think that the patch after my > signature is the correct approach to fix this bug. > > Thanks, > Jo=C3=A3o > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index ac278edd40..4f542137a8 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -352,14 +352,18 @@ project--remote-file-names > (concat remote-id file)) > local-files)))) > > +(defun project--buffer-uninteresting-p (buf) > + (and (string-prefix-p " " (buffer-name buf)) (null (buffer-file-name > buf)))) > + > (cl-defgeneric project-buffers (project) > "Return the list of all live buffers that belong to PROJECT." > (let ((root (expand-file-name (file-name-as-directory (project-root > project)))) > bufs) > (dolist (buf (buffer-list)) > - (when (string-prefix-p root (expand-file-name > - (buffer-local-value 'default-directory > buf))) > - (push buf bufs))) > + (unless (project--buffer-uninteresting-p buf) > + (when (string-prefix-p root (expand-file-name > + (buffer-local-value > 'default-directory buf))) > + (push buf bufs)))) > (nreverse bufs))) > > (defgroup project-vc nil > @@ -680,11 +684,12 @@ project-buffers > dd > bufs) > (dolist (buf (buffer-list)) > - (setq dd (expand-file-name (buffer-local-value 'default-directory > buf))) > - (when (and (string-prefix-p root dd) > - (not (cl-find-if (lambda (module) (string-prefix-p modu= le > dd)) > - modules))) > - (push buf bufs))) > + (unless (project--buffer-uninteresting-p buf) > + (setq dd (expand-file-name (buffer-local-value 'default-directory > buf))) > + (when (and (string-prefix-p root dd) > + (not (cl-find-if (lambda (module) (string-prefix-p > module dd)) > + modules))) > + (push buf bufs)))) > (nreverse bufs))) I still don't agree that this is the right interpretation of the issue or solution, but wouldn't it be better to add this to `project-kill-buffer-conditions'? The solution I would prefer is if project.el would define a sort of project-kill-hook, that Eglot would modify and make sure that `eglot-shutdown' is invoked before any buffer is killed.
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 17:16:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 13:16:28 2022
Received: from localhost ([127.0.0.1]:34194 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ooSy4-0007GX-14
for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:16:28 -0400
Received: from mail-oi1-f180.google.com ([209.85.167.180]:34436)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <joaotavora@HIDDEN>) id 1ooSy0-0007GF-No
for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:16:25 -0400
Received: by mail-oi1-f180.google.com with SMTP id y67so6817395oiy.1
for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 10:16:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=ycMia3wljRFmv1pqtmXYSvdA5HAZB/pKO4DIBamj1C4=;
b=CNpoGmX+RFd9K8JthTqdNkXT0/uoa2eVAhG5Z+VfR62fCigA9H3YVeiLwZibO71PIO
tZiZRRKiIzRYNwmGw7ZPWHIWdYqxtyiU/ze6FUed1DmOWsowWcU/rwrNlZXkDKz7KM8v
aFqNin1qZbgbNyaG73EUS4kH6q6pYJ4sR0BNbnNcv9WH5TfHE/Ew6hRoaFFCPVKyHSpi
w4ghq6yS3ItEKJpjBz0YUpH6Ss9bFabprUATi1VarTz1ID/vS5p+SM6NcgE02YpLrCTW
EKqbboCD+hk/NzjGKf+1f/c8WDQs8du/De3J4C+q2Qj65QKhmZCkVeSpCjuVsu4GfgsL
YVUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=ycMia3wljRFmv1pqtmXYSvdA5HAZB/pKO4DIBamj1C4=;
b=mno5Q5ZQ58+BldCv+fxy5McznwEWNlWaCr45ByejnGIaYU7rcjTYiZnAceYvyExKrY
bVmipYl+BK5cOFStNZN3Yf4WWWDYQRP1e/xWnUfTYG/Yr7/VA0L2JBr0Ogvi5WMafkNY
OZXkdvRPflu37lrwuzwvNEAOMHdwU7JRp/NvTZC9AXRAOdVr8DU8nw0NHig3GGVsgaUy
nqhkzT+IlKV2E25UdXK1yHUQEXWzWKMw2sptMnE9dINskYFpyHYkL3g3bl908+GUROjj
B1hPgh9ZxoLAuYpf1LOLcC/rsx8TCZAO36+V4lBnPTrg7cpLNgcDBmCL0t3NNtsDrjBk
E4aQ==
X-Gm-Message-State: ACrzQf3Q8XXTMQFGnjFW14xMB/21ImA6xOBdYmzQxXIv4AvC+xJa/Rnb
UgVJnNqU18RQcahm0kIUXqXhxm+nSKwXdnhuAus=
X-Google-Smtp-Source: AMsMyM66powm+w5OoOWbZstjTDqMxtTKAf7jd6zsSzofc53RqvBNXHndd9mOw/xm97vldCxclkY0kUK0uKa9eOpTfn0=
X-Received: by 2002:a05:6808:1a1f:b0:354:b33b:8b0d with SMTP id
bk31-20020a0568081a1f00b00354b33b8b0dmr8132203oib.171.1666977379059; Fri, 28
Oct 2022 10:16:19 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
In-Reply-To: <87sfj8umwb.fsf@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Fri, 28 Oct 2022 18:17:18 +0100
Message-ID: <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
Subject: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot
is running
To: Philip Kaludercic <philipk@HIDDEN>,
Manuel Uberti <manuel.uberti@HIDDEN>,
Dmitry Gutov <dgutov@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000870d2205ec1b6a2e"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 58839
Cc: 58839 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--000000000000870d2205ec1b6a2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic <philipk@HIDDEN>
wrote:
> When wanting to clean up behind a project I like to use C-x p k to get
> rid of everything I have opened related to it. If I was using Eglot and
> there is still an active LSP server running in the background, killing
> the project fails with these messages:
Thanks Philip. This was discussed at
https://github.com/joaotavora/eglot/discussions/822
Some more information is needed:
1. The error only happens when eglot-autoshutdown has been set to t by
the user.
2. When it has not been set to t, then the behavior is still not
correct, but the user may not notice it.
3. According to Manuel Uberti, the problem also happens with CIDER, a
Clojure IDE for Emacs. So it seems it is not exclusive to Eglot.
The problem happens because `project-kill-buffers` uses project.el's
sense of a project buffer, and then endeavours to kill all such buffers.
So far so good, but the determination of project buffers according
to `project-buffers` considers all buffers whose buffer-local default
directory starts with a given root of some project.
This is subtly wrong because it also considers buffers whose name starts
with space and without buffer-file-names, so-called "hidden buffers" which
are deemed "uninteresting" to the user (according to the Elisp manual).
They commonly function as implementation details of other packages, such
as Eglot (and possibly CIDER). These buffers are not normally visible
to the user in M-x ibuffer, switch-to-buffer, etc.
In Eglot's case, the buffer whose name is " EGLOT process..." is
created by eglot.el and then handed over to jsonrpc.el, which becomes
responsible for it.
Killing this buffer from Lisp using `kill-buffer` is incorrect because
it contradicts Eglot's user preferences eglot-autoreconnect and
eglot-autoshutdown:
1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the
process and confuses the LSP shutdown logic, which is a polite
"teardown" conversation with the LSP server. This is Philip's error.
2. If eglot-autoshutdown is nil but eglot-autoreconnect is non-nil (in
fact, these are the defaults), killing the buffer has the effect of
immediately restarting the connection, and thus re-creating the
buffer. The best that can happen is that nothing was achieved
and only time was wasted.
The fact is that the buffer in question is an internal Eglot implementation
detail that other packages should stay clear of.
In fact, I think that all hidden buffers can be considered thusly.
They're just like `--` symbols in obarray or in other symbol's plists:
they're visible to all Lisp packages but they are implementation details
that shouldn't be messed with except by the owner of such details.
Dmitry tells me that there was some discussion where it was determined
that it's somehow useful in project-kill-buffers to also target buffers
that the
user isn't aware of.
But I've not seen evidence of this usefulness. If there is indeed some,
I propose we come up with some convention so that it is possible for
packages to create buffers which are "definitely hidden and private and
not to me tinkered with". Such a convention could be starting the
buffer name with two spaces.
Whatever the convention, currently I think that the patch after my
signature is the correct approach to fix this bug.
Thanks,
Jo=C3=A3o
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..4f542137a8 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -352,14 +352,18 @@ project--remote-file-names
(concat remote-id file))
local-files))))
+(defun project--buffer-uninteresting-p (buf)
+ (and (string-prefix-p " " (buffer-name buf)) (null (buffer-file-name
buf))))
+
(cl-defgeneric project-buffers (project)
"Return the list of all live buffers that belong to PROJECT."
(let ((root (expand-file-name (file-name-as-directory (project-root
project))))
bufs)
(dolist (buf (buffer-list))
- (when (string-prefix-p root (expand-file-name
- (buffer-local-value 'default-directory
buf)))
- (push buf bufs)))
+ (unless (project--buffer-uninteresting-p buf)
+ (when (string-prefix-p root (expand-file-name
+ (buffer-local-value
'default-directory buf)))
+ (push buf bufs))))
(nreverse bufs)))
(defgroup project-vc nil
@@ -680,11 +684,12 @@ project-buffers
dd
bufs)
(dolist (buf (buffer-list))
- (setq dd (expand-file-name (buffer-local-value 'default-directory
buf)))
- (when (and (string-prefix-p root dd)
- (not (cl-find-if (lambda (module) (string-prefix-p module
dd))
- modules)))
- (push buf bufs)))
+ (unless (project--buffer-uninteresting-p buf)
+ (setq dd (expand-file-name (buffer-local-value 'default-directory
buf)))
+ (when (and (string-prefix-p root dd)
+ (not (cl-find-if (lambda (module) (string-prefix-p
module dd))
+ modules)))
+ (push buf bufs))))
(nreverse bufs)))
--000000000000870d2205ec1b6a2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic <<a h=
ref=3D"mailto:philipk@HIDDEN">philipk@HIDDEN</a>> wrote:<br><br>=
> When wanting to clean up behind a project I like to use C-x p k to get=
<br>> rid of everything I have opened related to it.=C2=A0 If I was usin=
g Eglot and<br>> there is still an active LSP server running in the back=
ground, killing<br>> the project fails with these messages:<br><br>Thank=
s Philip.=C2=A0 This was discussed at<br><br><a href=3D"https://github.com/=
joaotavora/eglot/discussions/822">https://github.com/joaotavora/eglot/discu=
ssions/822</a><br><br>Some more information is needed:<br><br>1. The error =
only happens when eglot-autoshutdown has been set to t by<br>=C2=A0 =C2=A0t=
he user.<br><br>2. When it has not been set to t, then the behavior is stil=
l not<br>=C2=A0 =C2=A0correct, but the user may not notice it.<br><br>3. Ac=
cording to Manuel Uberti, the problem also happens with CIDER, a<br>=C2=A0 =
=C2=A0Clojure IDE for Emacs.=C2=A0 So it seems it is not exclusive to Eglot=
.<br><br>The problem happens because `project-kill-buffers` uses project.el=
's<br>sense of a project buffer, and then endeavours to kill all such b=
uffers.<br><div><br></div><div>So far so good, but the determination of pro=
ject buffers according</div>to `project-buffers` considers all buffers whos=
e buffer-local default<br>directory starts with a given root of some projec=
t.<br><br>This is subtly wrong because it also considers buffers whose name=
starts<br>with space and without buffer-file-names, so-called "hidden=
buffers" which<br>are deemed "uninteresting" to the user (a=
ccording to the Elisp manual).<br>They commonly function as implementation =
details of other packages, such<br>as Eglot (and possibly CIDER).=C2=A0 The=
se buffers are not normally visible<br>to the user in M-x ibuffer, switch-t=
o-buffer, etc.<br><br>In Eglot's case, the buffer whose name is " =
EGLOT process..." is<br>created by eglot.el and then handed over to js=
onrpc.el, which becomes<br>responsible for it.<br><br>Killing this buffer f=
rom Lisp using `kill-buffer` is incorrect because<br>it contradicts Eglot&#=
39;s user preferences eglot-autoreconnect and<br>eglot-autoshutdown:<br><br=
>1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the<br>=
=C2=A0 =C2=A0process and confuses the LSP shutdown logic, which is a polite=
<br>=C2=A0 =C2=A0"teardown" conversation with the LSP server.=C2=
=A0 This is Philip's error.<br><br>2. If eglot-autoshutdown is nil but =
eglot-autoreconnect is non-nil (in<br>=C2=A0 =C2=A0fact, these are the defa=
ults), killing the buffer has the effect of<br>=C2=A0 =C2=A0immediately res=
tarting the connection, and thus re-creating the<br><div>=C2=A0 =C2=A0buffe=
r.=C2=A0 The best that can happen is that nothing was achieved <br></div><d=
iv>=C2=A0=C2=A0 and only time was wasted.</div><br><div>The fact is that th=
e buffer in question is an internal Eglot implementation <br></div><div>det=
ail that other packages should stay clear of.=C2=A0 <br></div><br>In fact, =
I think that all hidden buffers can be considered thusly.<br>They're ju=
st like `--` symbols in obarray or in other symbol's plists:<br>they=
9;re visible to all Lisp packages but they are implementation details<br><d=
iv>that shouldn't be messed with except by the owner of such details.</=
div><br>Dmitry tells me that there was some discussion where it was determi=
ned<br><div>that it's somehow useful in project-kill-buffers to also ta=
rget buffers that the</div><div>user isn't aware of.<br></div><br>But I=
've not seen evidence of this usefulness.=C2=A0 If there is indeed some=
,<br>I propose we come up with some convention so that it is possible for<b=
r>packages to create buffers which are "definitely hidden and private =
and<br>not to me tinkered with".=C2=A0 Such a convention could be star=
ting the<br>buffer name with two spaces.<br><br>Whatever the convention, cu=
rrently I think that the patch after my<br><div>signature is the correct ap=
proach to fix this bug.</div><div><br></div><div>Thanks,<br></div><div>Jo=
=C3=A3o<br></div><div><br></div><div>diff --git a/lisp/progmodes/project.el=
b/lisp/progmodes/project.el<br>index ac278edd40..4f542137a8 100644<br>--- =
a/lisp/progmodes/project.el<br>+++ b/lisp/progmodes/project.el<br>@@ -352,1=
4 +352,18 @@ project--remote-file-names<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(concat remote-id file))<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0local-files))))<br>=C2=A0<br>+(def=
un project--buffer-uninteresting-p (buf)<br>+ =C2=A0(and (string-prefix-p &=
quot; " (buffer-name buf)) (null (buffer-file-name buf))))<br>+<br>=C2=
=A0(cl-defgeneric project-buffers (project)<br>=C2=A0 =C2=A0"Return th=
e list of all live buffers that belong to PROJECT."<br>=C2=A0 =C2=A0(l=
et ((root (expand-file-name (file-name-as-directory (project-root project))=
))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bufs)<br>=C2=A0 =C2=A0 =C2=A0(dolis=
t (buf (buffer-list))<br>- =C2=A0 =C2=A0 =C2=A0(when (string-prefix-p root =
(expand-file-name<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-=
local-value 'default-directory buf)))<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0(=
push buf bufs)))<br>+ =C2=A0 =C2=A0 =C2=A0(unless (project--buffer-unintere=
sting-p buf)<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (string-prefix-p root (e=
xpand-file-name<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=
buffer-local-value 'default-directory buf)))<br>+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0(push buf bufs))))<br>=C2=A0 =C2=A0 =C2=A0(nreverse bufs)))<br=
>=C2=A0<br>=C2=A0(defgroup project-vc nil<br>@@ -680,11 +684,12 @@ project-=
buffers<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dd<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 bufs)<br>=C2=A0 =C2=A0 =C2=A0(dolist (buf (buffer-list))<br>-=
=C2=A0 =C2=A0 =C2=A0(setq dd (expand-file-name (buffer-local-value 'de=
fault-directory buf)))<br>- =C2=A0 =C2=A0 =C2=A0(when (and (string-prefix-p=
root dd)<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (not=
(cl-find-if (lambda (module) (string-prefix-p module dd))<br>- =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modules)))<br>- =C2=A0 =C2=A0 =C2=A0 =C2=
=A0(push buf bufs)))<br>+ =C2=A0 =C2=A0 =C2=A0(unless (project--buffer-unin=
teresting-p buf)<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq dd (expand-file-name=
(buffer-local-value 'default-directory buf)))<br>+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(when (and (string-prefix-p root dd)<br>+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (not (cl-find-if (lambda (module)=
(string-prefix-p module dd))<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0modules)))<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(push buf bu=
fs))))<br>=C2=A0 =C2=A0 =C2=A0(nreverse bufs)))<br>=C2=A0<br>=C2=A0=0C</div=
></div>
--000000000000870d2205ec1b6a2e--
bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 28 Oct 2022 12:57:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 28 08:57:14 2022 Received: from localhost ([127.0.0.1]:60646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ooOvB-0006hT-Ay for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 08:57:14 -0400 Received: from lists.gnu.org ([209.51.188.17]:33086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <philipk@HIDDEN>) id 1ooOv6-0006hI-Fd for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 08:57:12 -0400 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 <philipk@HIDDEN>) id 1ooOv6-0002gZ-4j for bug-gnu-emacs@HIDDEN; Fri, 28 Oct 2022 08:57:08 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <philipk@HIDDEN>) id 1ooOuu-0000sU-Vy for bug-gnu-emacs@HIDDEN; Fri, 28 Oct 2022 08:57:07 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 58C3E240103 for <bug-gnu-emacs@HIDDEN>; Fri, 28 Oct 2022 14:56:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666961813; bh=rwMngjQqpqHOUGbbnskZAYh0IrzwtVwNYofRGu/9Izo=; h=From:To:Subject:Autocrypt:Date:From; b=FqKXlZUPws62nBuGcvQe172+Ggaz5bnvIYFXFLa25Qo3VddqY49TB11urf3nzzhS2 UW3TR+L2FsbnQ0s9G34Q4wRC10s+KvsmXUGz0K5Ynd0upM5oDH83QlIgojbhAF459n cLNG6HGnN/8bg+L0UMMeF5uWKxM7SY/HqPyuSJXS9JiT/OO3UMemGwKapsf+2Qdl4q 0uBRqEZwRSaTCryEBhyOGFpfOS+vYZGaNVROjbnTBMXsKcUHYNUUTY3iHfmZXlO1np xF2WHu4XVxmSZ8z5Lz5RBvUMp4sezjE+qIUwl8BmixfGxKrlgwlnhd6GzN0evrPTPW jvGHQDHc+qBHA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MzMxw6Vsfz9rxP for <bug-gnu-emacs@HIDDEN>; Fri, 28 Oct 2022 14:56:52 +0200 (CEST) From: Philip Kaludercic <philipk@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 29.0.50; project-kill-buffer fails when Eglot is running Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Fri, 28 Oct 2022 12:56:52 +0000 Message-ID: <87sfj8umwb.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@HIDDEN; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) When wanting to clean up behind a project I like to use C-x p k to get rid of everything I have opened related to it. If I was using Eglot and there is still an active LSP server running in the background, killing the project fails with these messages: --8<---------------cut here---------------start------------->8--- Kill 7 buffers in ~/Source/sgo/? (y or n) y [eglot] error sending textDocument/didClose: (error Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup ) [eglot] error sending textDocument/didClose: (error Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup ) [eglot] error sending textDocument/didClose: (error Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup ) [eglot] Asking EGLOT (sgo/(c-mode c++-mode)) politely to terminate [jsonrpc] Server exited with status 1 down-list: Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup --8<---------------cut here---------------end--------------->8--- Running C-x p k a second time does succeed. The issue was previously also discussed here: https://github.com/joaotavora/eglot/discussions/822#discussioncomment-3986357 In GNU Emacs 29.0.50 (build 23, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-10-22 built on rhea Repository revision: ab283bddb2505e767bdf08b063c648b87d71d33a Repository branch: feature/package+vc System Description: Fedora Linux 36 (Workstation Edition) Configured using: 'configure --with-pgtk --with-imagemagick' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK JPEG JSON LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: utf-8-unix Major mode: ELisp/d Minor modes in effect: TeX-PDF-mode: t rcirc-color-mode: t rcirc-track-minor-mode: t global-git-commit-mode: t magit-auto-revert-mode: t outline-minor-mode: t flymake-mode: t yas-minor-mode: t flyspell-mode: t repeat-mode: t display-battery-mode: t display-time-mode: t diff-hl-flydiff-mode: t diff-hl-mode: t winner-mode: t windmove-mode: t corfu-history-mode: t corfu-mode: t vertico-multiform-mode: t vertico-mode: t electric-pair-mode: t shell-dirtrack-mode: t recentf-mode: t save-place-mode: t savehist-mode: t pixel-scroll-precision-mode: t pixel-scroll-mode: t xterm-mouse-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tab-bar-mode: t file-name-shadow-mode: t context-menu-mode: t global-font-lock-mode: t font-lock-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/philip/.config/emacs/site-lisp/flymake-proselint/flymake-proselint hides /home/philip/.config/emacs/elpa/flymake-proselint-0.3.0/flymake-proselint /home/philip/.config/emacs/elpa/transient-0.3.7/transient hides /home/philip/Source/emacs/lisp/transient /home/philip/.config/emacs/elpa/xref-1.5.1/xref hides /home/philip/Source/emacs/lisp/progmodes/xref Features: (shadow emacsbug go-mode find-file etags fileloop nroff-mode dictionary dictionary-connection vertico-buffer loadhist embark ffap url-cache url-http url-auth url-gw display-line-numbers vc-annotate reposition multi-prompt two-column shortdoc rect gnus-draft ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar org-agenda org-refile ox-html table ox-ascii ox-publish ox reftex-sel cursor-sensor reftex-parse reftex-toc consult-vertico consult compat-28 magit-bookmark bookmark em-unix em-term term ehelp em-script em-prompt em-ls em-hist em-pred em-glob em-extpipe em-cmpl em-dirs esh-var em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util ange-ftp whitespace preview reporter desktop frameset tex-fold reftex-dcr reftex-auc reftex reftex-loaddefs reftex-vars font-latex latex latex-flymake tex-ispell tex-style tex texmathp tex-mode latexenc mhtml-mode css-mode js sgml-mode facemenu gnus-search eieio-opt mailalias smtpmail rcirc-color rcirc autocrypt-message ecomplete flow-fill mm-archive sh-script smie executable quail org-element avl-tree generator ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview doc-view jka-compr image-mode exif ol-bibtex ol-bbdb ol-w3m ol-doi org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol org-keys oc org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs ef-bio-theme ef-autumn-theme ef-frost-theme ef-night-theme ietf-drums-date sort smiley gnus-cite mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check qp gnus-async gnus-bcklg gnus-ml disp-table autocrypt-gnus autocrypt nndraft nnmh utf-7 nnfolder epa-file network-stream nsm gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig nntp gnus-cache gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win ef-duo-dark-theme ef-trio-dark-theme ef-trio-light-theme ef-themes cus-theme flymake-proselint xdg apropos tabify cus-start cl-print mule-util pulse markdown-mode color profiler avy copyright cc-mode advice cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-langs cc-vars cc-defs cc-bytecomp magit-extras goto-addr face-remap magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func edebug magit-diff smerge-mode git-commit log-edit message yank-media puny rfc822 mml mml-sec epa mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor server magit-mode transient edmacro kmacro magit-git magit-section magit-utils crm dash dired-aux gnus-dired autorevert char-fold misearch multi-isearch bug-reference buffer-env compat vc-backup vc-fossil vc-hg vc-git vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs eglot array filenotify jsonrpc ert debug backtrace xref imenu find-func vertico-directory orderless vertico-flat noutline outline so-long checkdoc flymake-proc flymake warnings yasnippet-snippets yasnippet flyspell ispell init auth-source-pass repeat project battery dbus xml shell-command+ thingatpt dired-x time sendmail rfc2047 rfc2045 ietf-drums gnus nnheader gnus-util mail-utils range mm-util mail-prsvr finder-inf diff-hl-flydiff diff diff-hl log-view pcvs-util vc-dir ewoc vc dired dired-loaddefs vc-dispatcher diff-mode hippie-exp winner windmove corfu-history corfu vertico-multiform vertico elec-pair tramp-sh tramp tramp-cache time-stamp tramp-loaddefs trampver tramp-integration cus-edit pp icons tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp format-spec recentf tree-widget wid-edit saveplace savehist pixel-scroll cua-base xt-mouse modus-operandi-theme modus-themes cus-load setup site-lisp auto-site loaddefs-gen lisp-mnt auctex-autoloads tex-site ef-themes-autoloads xr-autoloads consult-autoloads corfu-autoloads focus-autoloads vertico-autoloads debbugs-autoloads rcirc-color-autoloads inspector-autoloads flymake-proselint-autoloads geiser-guile-autoloads xref-autoloads vc-fossil-autoloads diff-hl-autoloads crdt-autoloads embark-autoloads magit-autoloads buffer-env-autoloads compat-autoloads geiser-chibi-autoloads geiser-impl help-fns radix-tree geiser-custom geiser-base geiser-autoloads slime-autoloads transient-autoloads info speedbar ezimage dframe package let-alist cl-extra help-mode browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source eieio eieio-core password-cache json map byte-opt bytecomp byte-compile derived cl-seq compile easy-mmode files-x rx text-property-search comint ansi-osc ansi-color ring cconv cl-macs gv pcase url-vars inline epg rfc6068 epg-config subr-x cl-loaddefs cl-lib rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo gtk pgtk multi-tty make-network-process emacs) Memory information: ((conses 16 1976854 260727) (symbols 48 63144 155) (strings 32 275874 35428) (string-bytes 1 8519084) (vectors 16 169530) (vector-slots 8 3195578 164029) (floats 8 1123 670) (intervals 56 51553 1925) (buffers 1000 89))
Philip Kaludercic <philipk@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#58839; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.