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 07:48:16 +0000 Message-ID: <871qqlu79b.fsf@gmail.com> References: <87sfj8umwb.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> <87h6zihq3q.fsf@posteo.net> <877d0ehlnb.fsf@posteo.net> <87edumg4fd.fsf@posteo.net> <874jvig2rp.fsf@posteo.net> <87edulu8ly.fsf@gmail.com> <87wn8dbyq1.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="7615"; 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 08:48:42 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 1oq8UM-0001kP-0P for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 08:48:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oq8U3-00041v-BT; Wed, 02 Nov 2022 03:48:24 -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 1oq8Ti-00041m-FT for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 03:48: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 1oq8Ti-0002Se-4C for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 03:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oq8Th-0001UA-Kg for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 03:48: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 07:48: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.16673752335572 (code B ref 58839); Wed, 02 Nov 2022 07:48:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:47:13 +0000 Original-Received: from localhost ([127.0.0.1]:44837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq8Sv-0001Ro-E3 for submit@debbugs.gnu.org; Wed, 02 Nov 2022 03:47:13 -0400 Original-Received: from mail-wr1-f41.google.com ([209.85.221.41]:36427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq8Su-0001Rb-31 for 58839@debbugs.gnu.org; Wed, 02 Nov 2022 03:47:12 -0400 Original-Received: by mail-wr1-f41.google.com with SMTP id j15so23244513wrq.3 for <58839@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) Original-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) In-Reply-To: <87wn8dbyq1.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 02 Nov 2022 07:29:58 +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:246846 Archived-At: Philip Kaludercic writes: > Jo=C3=A3o T=C3=A1vora writes: > >> Philip Kaludercic 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?