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: Mon, 16 Aug 2021 04:53:59 +0100 Message-ID: References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <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> 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="15015"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 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 Mon Aug 16 05:55:12 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 1mFTiR-0003gl-F5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 05:55:11 +0200 Original-Received: from localhost ([::1]:39644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFTiP-0001J1-Jw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Aug 2021 23:55:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFTiI-0001Ii-IH for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2021 23:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36566) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFTiI-0003xT-72 for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2021 23:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFTiI-0001vW-0B for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2021 23:55: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: Mon, 16 Aug 2021 03:55:01 +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.16290860697365 (code B ref 47711); Mon, 16 Aug 2021 03:55:01 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 03:54:29 +0000 Original-Received: from localhost ([127.0.0.1]:48112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFThh-0001ua-Pb for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:54:29 -0400 Original-Received: from mail-pj1-f48.google.com ([209.85.216.48]:53780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFThY-0001uB-Q7; Sun, 15 Aug 2021 23:54:20 -0400 Original-Received: by mail-pj1-f48.google.com with SMTP id j1so24399797pjv.3; Sun, 15 Aug 2021 20:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5U8epICC1itkFK7Ot8G6B3eKqRd2LOVPQEmirX1WEQI=; b=jxdnZS1FpAM8YS/mMD7kzFj0mtHzMu3zXrle8ijqhVn4K8vxhSEBK8XBDTWW5Ulfal 1TfJ53Kp3XMldOSbitiN1Wg8G2YOSOcGxcnRVWaerr3OoosNzJnnf955hL4RUyKe0qnc pocnoLbXK8bt8JipFWmDnGkiseoDYsLDDgzFgawd/myMJ61DeVRPE05EZi0OU8p6iZbp FaAlPsllupTojXEf9QoNZqfHyMs19zhExBmB5bo6KorUm1or2z4LOwsb8vL9+a/GZjvX T+6TWRp6Z3Nmys42lvybHuoLEeYKHCsl2lks6DL8f8IyHUzvyRYJ/1tHc019p1kIEHTx IpPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5U8epICC1itkFK7Ot8G6B3eKqRd2LOVPQEmirX1WEQI=; b=bF6ZSo/YG7xb1vO4uR3HlVYbBRgLpSHjvkM7xk9QUc0jMxZQMnQnMFj9qE2bBFESSA cAnV7A+sAqZ/JvtFxM2wTF2RjMzDl3qBHPfbvSz2edHNBH6lkhmLd1+2CtxyeNRKOrl0 Lx06gyypEbtaho7INdSwX+vf+iIY0OsagTRA3It5apmrOIECO8yk6bYTV7YlVApp8tb/ N4cx8A6mP/FY6PEyT7nOmXjl8JOPLZljrdQeGXYrscZlyAReewtWyiDGMrhc7OHlcMzD A8UNBKTBhmaV3f0PD6n4Ro6q6frFnfysi/o52/pwbTAeQt71rk2AYkTwmMZqs+aE5biV sGDA== X-Gm-Message-State: AOAM533jrgNLT+djLmOQNZLGETco2HSzVqy8msbSi8ntCgP5HyurBjIC 5Hm2rPp0A5bBhc+WVdDjLsOIPrWHBeUKfGLdGtg= X-Google-Smtp-Source: ABdhPJw/eF2aVy16C6VGDXYzzJxISRy2gtTQ/5B/MqJg9pUwG0KUwr2/9Dw/q+u73fbyzqNfFi+1CZaXBjlEq2mMRkA= X-Received: by 2002:a17:902:d487:b0:12d:89d3:a6b with SMTP id c7-20020a170902d48700b0012d89d30a6bmr11825580plg.52.1629086050783; Sun, 15 Aug 2021 20:54:10 -0700 (PDT) In-Reply-To: <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> 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:211962 Archived-At: On Mon, Aug 16, 2021 at 4:31 AM Dmitry Gutov wrote: > > On 16.08.2021 06:27, Jo=C3=A3o T=C3=A1vora wrote: > > I wouldn't mind that at all. For me, it's quite the same as evaluating > > (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along = with > > all the other byte-compilation stuff already there. > > Those serve a real purpose, not just work as an accidental cache for > some earlier computation. Caches also serve "a real purpose". the gv-expander there would be the "cache of an earlier computation". And I'm not sure what "accidental" means, but if it means "implementation detail for something I don't care about", I agree `completion-score` is "accidental". Should it be called `completion-score-internal-cache-dont-look-here`? Maybe. Bottom line here is that an outside observer has no clue, and shouldn't need or want to have a clue, on what "foreign" properties attached to strings or symbols are meant. This is why Eli says, and I agree, that if the property isn't display related, it's all good. No-one but the setter and reader of that particular property mind. The CL systems I've worked with use package qualifiers to fine-grain this even further, but they use the same principle. That Elisp allows a string property list doesn't really make a difference IMO. And none of this really really matters to the discussion. If we absolutely had to store these associations away from the string plist, (for some aesthetic reason, I guess), we could just use hash-tables. Then we could return the string unchanged (and uncopied) and largely keep performance intact. But why do it, since a string plist is a such a nice place to do these associations and there's -- apart from your aesthetics considerations -- 0 drawbacks identified? Jo=C3=A3o T=C3=A1vora