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: Wed, 02 Nov 2022 08:41:47 +0000 Message-ID: <87r0ylsq7o.fsf@gmail.com> References: <87sfj8umwb.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> <87h6zihq3q.fsf@posteo.net> <877d0ehlnb.fsf@posteo.net> <87edumg4fd.fsf@posteo.net> <874jvig2rp.fsf@posteo.net> <87edulu8ly.fsf@gmail.com> <87wn8dbyq1.fsf@posteo.net> <871qqlu79b.fsf@gmail.com> <877d0dbwbu.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32373"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 58839@debbugs.gnu.org, Dmitry Gutov To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 09:41:12 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 1oq9JA-0008Dq-IW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 09:41:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oq9J3-0002bn-SO; Wed, 02 Nov 2022 04:41:05 -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 1oq9J0-0002aL-JM for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:41:04 -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 1oq9J0-0002og-7m for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oq9Iz-0002pM-RA for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:41: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: Wed, 02 Nov 2022 08:41: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.166737844710839 (code B ref 58839); Wed, 02 Nov 2022 08:41:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:40:47 +0000 Original-Received: from localhost ([127.0.0.1]:44898 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq9Ik-0002ok-Nq for submit@debbugs.gnu.org; Wed, 02 Nov 2022 04:40:47 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:41793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq9If-0002oO-LC for 58839@debbugs.gnu.org; Wed, 02 Nov 2022 04:40:44 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id w14so23391001wru.8 for <58839@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) Original-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) In-Reply-To: <877d0dbwbu.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 02 Nov 2022 08:21:41 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246851 Archived-At: Philip Kaludercic 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