From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler 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 11:08:31 +0200 Message-ID: <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> References: <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> <87a6lihv7b.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27412"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 47711@debbugs.gnu.org, 48841@debbugs.gnu.org, Stefan Monnier To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 11:09: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 1mFYcK-0006xJ-0r for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 11:09:12 +0200 Original-Received: from localhost ([::1]:45852 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFYcI-00061K-SM for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 05:09:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50374) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFYcA-0005yT-SF for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 05:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36944) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFYcA-0004pP-JU for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 05:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFYcA-0003zd-Dz for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 05:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 09:09: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.162910493515329 (code B ref 47711); Mon, 16 Aug 2021 09:09:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 09:08:55 +0000 Original-Received: from localhost ([127.0.0.1]:48488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYbp-0003yu-Ms for submit@debbugs.gnu.org; Mon, 16 Aug 2021 05:08:55 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:33691 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYbn-0003ye-BM; Mon, 16 Aug 2021 05:08:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GJcT/T5DVTuHMs67rjtK1AoQVRPLwkXyW16s1GuaJfQ=; b=mcXl/177spo4DFSgMO5rICqYIR 75/3YzAOxMWILnRCf6B7BUnCXi26il3qrnACsZKMwWM3/SAgDOzvgyBXxl68lpbg2q0raDMtzo6mp gQxuCbALUXXoCHXyqhjjJZKsttKSS9itzkbIzlbycWfYXP53dAxFWI7m7QnRnQHu90EU=; In-Reply-To: <87a6lihv7b.fsf@gmail.com> Content-Language: en-US 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:211974 Archived-At: On 8/16/21 6:25 AM, João Távora wrote: > Yes, I currently conclude that there are 0 drawbacks identified to > creating, _via_ string properties, an association of, say, property > 'joaot/answer' with value '42' to _any_ string in my current and future > Emacs runtimes. > > I conclude that because --- apart from your aesthetics considerations > ("do we really want to see...") --- I have not seen identification of > such drawbacks. Have I missed any? There are serious drawbacks of attaching "private" string properties to arbitrary strings. For once it complicates debugging seriously if there are suddenly string properties attached to symbol names. It also leads to a potential memory leak. But even if we could chose this approach with global side-effects I don't see a reason to do it given the approach I am proposing in my patch, which avoids these problems entirely. 1. My approach decomposes the already existing completion machinery into two steps: 1. filtering and 2. highlighting. It does not change the fundamentals of the completion machinery. This decomposition of the existing infrastructure is also what leads to the small number of added lines to minibuffer.el, even if the patch itself is not as small as we would like to have it. 2. Why take the chances of introducing potentially harmful global side effects by attaching string properties to arbitrary strings if we can avoid it easily? 3. The `completion-filter-completions` API is the fastest possible API for filtering since it does not change the strings at all, it does not attach string properties or modify the strings in any other way. By construction, it is a pure function which only filters the list of candidates. This makes the function easy to use and easy to reason about. An API which adds private properties to the strings cannot be as fast and non-intrusive. 4. If 'completion-all-completions' does indeed get slower thanks to my patch, it is a performance regression of my patch. I will fix this. And I thank you João for bringing this to my attention. However one should also consider that in the end, 'fido-mode' and 'icomplete-mode' should move to the new API 'completion-filter-completions' such that they benefit from the fast filtering and only copy and highlight the actually displayed strings. Given this a potential regression of 'completion-all-completions' would matter less for the incrementally updating UIs. But of course I feel the same way as João - a performance regression in the API 'completion-all-completions' is unacceptable. It will be fixed. Daniel