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#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Tue, 17 Aug 2021 09:59:25 +0100 Message-ID: <87zgtgxx8y.fsf@gmail.com> References: <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> <87tujpgscj.fsf@gmail.com> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> 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="20830"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Mendler , larsi@gnus.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 17 11:00:14 2021 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 1mFuxB-0005Ak-PN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Aug 2021 11:00:13 +0200 Original-Received: from localhost ([::1]:33670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFuxA-0003jj-6C for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Aug 2021 05:00:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFux1-0003iY-3p for bug-gnu-emacs@gnu.org; Tue, 17 Aug 2021 05:00:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40115) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFux0-0007SO-Qp for bug-gnu-emacs@gnu.org; Tue, 17 Aug 2021 05:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFux0-0001tQ-PI for bug-gnu-emacs@gnu.org; Tue, 17 Aug 2021 05:00:02 -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, 17 Aug 2021 09:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47711 X-GNU-PR-Package: emacs Original-Received: via spool by 47711-submit@debbugs.gnu.org id=B47711.16291907777196 (code B ref 47711); Tue, 17 Aug 2021 09:00:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 17 Aug 2021 08:59:37 +0000 Original-Received: from localhost ([127.0.0.1]:51656 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFuwb-0001rv-8Z for submit@debbugs.gnu.org; Tue, 17 Aug 2021 04:59:37 -0400 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:54956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFuwZ-0001rc-Ak; Tue, 17 Aug 2021 04:59:36 -0400 Original-Received: by mail-wm1-f48.google.com with SMTP id g138so13204806wmg.4; Tue, 17 Aug 2021 01:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=/dHRq1CLiHWhD7Jq2ZxdiJWP1UyGng3ccHVR6VjpgyM=; b=uRDRDoT/DLWGL+UByQK9yEGAK9aBW2hYBmdngJuA9OPx9uJZ+BeOXDRSm+VPC0KRgd la0DKIME4lGkwUhJcVm1dye40ZOHVv/Q5OkI1D3UNdZ5AK852x7Whr6HJyhP8QnB5o43 N7LFKV4URwZm70qHY1+kitqhil17pjpdmjTjzk+QQFcczyUfsqak8mzqIj/sDskvV6Sl cw/RxSXWRJQDpFTmV1PfkN85dTSjTPMi+OeHHtlygKRLb2wI1PaDK4KKLXtmGBHJV19E lCdat8KvBD+tTlx/eo0hIBjT3KZuswe+gj10JX+5YoBsRR8qaon29A9bJ4nXg2kAovI0 3diQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=/dHRq1CLiHWhD7Jq2ZxdiJWP1UyGng3ccHVR6VjpgyM=; b=CohTlTsyqLQUfTlfLd1teU+aXLps2dPwteDsMrmbks2fpOdpNEwvMZcWmlJn3nyQly ISi1LV8P/oCDzuxbYsaHiMLcQw+zCuJpahjsG6pkKpa0mrH6IEdnJuNxXQEW2Mkmh1NE AY9rLAzaIyduZsC11TUCId8d5qym2AE30uvzcM9MrXJEf76YTQzkKRi/wPmbYfa910G5 LEGl3IMSfV+ixEpLKyvZNhHDxU+tt/GlQnbiS1rexAoRmFAdNkW21YXvG81z0fgWWMzu TJn2TlvOLqlT0kS2OzMR+rGm6dBzZgUju43VTk06IiWHDWtTSDboKhFjoc6m6xVochl8 NCnw== X-Gm-Message-State: AOAM530FmEpHsjyLMmQpDdd8sp/vyJ7qfG07H3GO+E+9V+NKJ9g4dQJc Rw5IXJQ24uGJ9ajgmLjRHhOBcOIsfYc= X-Google-Smtp-Source: ABdhPJwsfqLedihw68Sh6MbVaQGXzHfs8AshozH8sIDGzQTLk6wiYmR8HdnRBL+YIyvvhE6u4fPRAw== X-Received: by 2002:a7b:c5d2:: with SMTP id n18mr2266047wmk.97.1629190768886; Tue, 17 Aug 2021 01:59:28 -0700 (PDT) Original-Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id g21sm1449040wmk.8.2021.08.17.01.59.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 01:59:28 -0700 (PDT) In-Reply-To: <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> (Dmitry Gutov's message of "Tue, 17 Aug 2021 05:08:15 +0300") 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212073 Archived-At: Dmitry Gutov writes: > On 16.08.2021 21:25, Jo=C3=A3o T=C3=A1vora wrote: >> I've made it faster, now very close to the string-propertizing approach, >> itself very close to the theoretical best (which is no copy, no >> highlight). See the tip of the >> scratch/icomplete-lazy-highlight-no-string-props branch, which I had to >> rewrite (some Git flub-up). All benchmarks after sig. > > Thanks. I've read it now. > > This implementation style (quick exfiltration via a dynamic var with > some special-cased logic) reminds me of the recent changes to eldoc, > really not my cup of tea. I'm sorry, but I'm not drinking from your herbarium. Googling for "exfiltration" brings up "malware" and data security. Why is mine "quick" at that? Is this some kind of metaphor? And what does "some special-cased logic" refer to exactly? I see as much similarity to Eldoc and I do to the Sistine chapel. The only thing I understand, I think, is "dynamic var". If you mean the variable 'completion-lazy-hilit', notice it is not necessarily used as dynamic var (in fact in icomplete.el it's just a buffer-local var). As I explained elsewhere, if the completion machinery had a realiable abstraction for "session" I would use that.=20=20 I don't think it does, does it? Currently, it's the frontend who holds that knowledge. It will either have an object representing it (maybe a fancy CLOS thing); or a stack frame with some kind of command loop; or, in the case of icomplete, a minibuffer session delineated by kill-all-local-variables. So, for icomplete.el, setting that variable buffer-locally is the appropriate thing. For the command-loopy frontend, dynamically binding it will be. The the objecty frontend, the object itself it proabably a good value for complation-lazy.hilit. For completion-capf, if you cared to optimize it with this stuff, it will likely be ... something something. Anyway, the "implementation style" I went for is speed, brevity and a decent docstring. And it'd be a bit shorter if it used string properties... > At the very least, though, you have done the work of proving that the > no-string-propertization approach can be just as fast. Thank you for > that. You're welcome. Not really just as fast, but in the big-O ballpark, of course. I had hoped to show also that the particular choice of global structure for string/symbol/whatever association is irrelevant. I'm still missing the imminent catastrophe (that is so clear to you) of the put-text-property approach. I'd like these slower and more complex techniques to appease more than superstition. > A hash table with :test 'eq is a good choice. I'd be happy to try to > tweak it further, but it also seems that at this point we can > transition to the discussion about what kind of implementation style > we want, since the performance is proven to be more or less on par. > > Though of course that should start with an alternative patch which > adds icomplete support as well (either Daniel does it, or I'll give it > a try). I'm curious to see those, yes. But Eli pointed out on, two different APIs will need to cohabitate since the new API won't kill off the old. To be very clear, I'm interested in the performance of Daniel's patch, not really in insufferable claims of its beauty and virginity. minibuffer.el is a great big mess, I'll leave it to the Great Designers of the Big Redesign, godspeed to them. Currently, I just want changes to not assassinate, in speed or form, icomplete.el or the flex completion style, two fundamental daily drivers to my work, and other's work. So if/when Daniel's patch doesn't do any of that (it seems that it currently does), I'll be all for it. Jo=C3=A3o