From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Date: Tue, 1 Nov 2022 10:59:41 +0000 Message-ID: References: <87sfj8umwb.fsf@posteo.net> <87edur3lil.fsf@posteo.net> <87a65f3j40.fsf@posteo.net> <213f3549-de4e-25a7-5e27-d13893e557bc@yandex.ru> <87zgdfwkle.fsf@gmail.com> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@yandex.ru> <87v8o3wgq1.fsf@gmail.com> <87ilk2x1si.fsf@gmail.com> <871qqq7l9p.fsf@posteo.net> <87eduqwekz.fsf@gmail.com> <87wn8invbx.fsf@posteo.net> <877d0iw8iq.fsf@gmail.com> <837d0hhlke.fsf@gnu.org> <46ff0065-5645-ef1e-2621-242fb6a73f98@yandex.ru> <87v8o0uxn5.fsf@gmail.com> <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> <87edunvhf2.fsf@gmail.com> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@yandex.ru> <87tu3jgdbv.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000776cca05ec669ba7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1601"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , manuel.uberti@inventati.org, 58839@debbugs.gnu.org, Dmitry Gutov To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 01 11:59:21 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opozJ-0000Ck-7c for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Nov 2022 11:59:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opoz2-0006Ye-LC; Tue, 01 Nov 2022 06:59:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opoz0-0006YQ-Sn for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 06:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1opoz0-0001FP-1j for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 06:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1opoyz-0003x4-Np for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 06:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2022 10:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58839 X-GNU-PR-Package: emacs Original-Received: via spool by 58839-submit@debbugs.gnu.org id=B58839.166730033015168 (code B ref 58839); Tue, 01 Nov 2022 10:59:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:58:50 +0000 Original-Received: from localhost ([127.0.0.1]:42843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opoyo-0003wZ-1r for submit@debbugs.gnu.org; Tue, 01 Nov 2022 06:58:50 -0400 Original-Received: from mail-ot1-f52.google.com ([209.85.210.52]:44863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opoym-0003wL-Cv for 58839@debbugs.gnu.org; Tue, 01 Nov 2022 06:58:48 -0400 Original-Received: by mail-ot1-f52.google.com with SMTP id p8-20020a056830130800b0066bb73cf3bcso8253466otq.11 for <58839@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) In-Reply-To: <87tu3jgdbv.fsf@posteo.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246764 Archived-At: --000000000000776cca05ec669ba7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic 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
On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <philipk@posteo.net> 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 ha= s
already found usage in a number of spots in core Emacs.=C2=A0 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 reinven= ting ... unary predicate
function of a buffer?

I'm not fond of these mini-languages because they'r= e less expressive, they
end up being only minimally less complica= ted and bug-prone, they can't
automatically be byte-compiled = for efficiency, and they can't automatically
be byte-compiled= for correctness/diagnostics.=C2=A0 If one makes a mistake,
= the backtrace is much more complicated.

So these m= ini-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 pr= oject.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.

<= div>Jo=C3=A3o
--000000000000776cca05ec669ba7--