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 12:52:58 +0200 Message-ID: References: <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> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> 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="27685"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , 47711@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 12:54:11 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 1mFaFv-0006wd-15 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 12:54:11 +0200 Original-Received: from localhost ([::1]:60094 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFaFt-000070-O8 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 06:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFaFn-00006e-4L for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 06:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37077) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFaFm-0002XP-Tx for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 06:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFaFm-00071S-Ea for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 06:54: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 10:54: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.162911119026921 (code B ref 47711); Mon, 16 Aug 2021 10:54:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 10:53:10 +0000 Original-Received: from localhost ([127.0.0.1]:48623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFaEv-000701-S4 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 06:53:10 -0400 Original-Received: from server.qxqx.de ([178.63.65.180]:42099 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFaEt-0006zS-Mq; Mon, 16 Aug 2021 06:53:08 -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=/fVONndn1d2yojf57smO1XDuVRiSgpuk9VBMHyJfqo0=; b=IG5RSU61Y3C7Qtn3VtFY1CebtN +QPuxDouSXj1jJDLk3YuN8NerQGacWg826fbv27K1W4K4SkfLPHt6nBueSDh5KslUAx1/MigfCm+o USkrYrDdUGpOqnmNw6GjAa54BOEu+YC3aOsZg6Zvz6MbuekLzZ8IqlAsoY3ZQ21Bv2QQ=; In-Reply-To: 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:211978 Archived-At: On 8/16/21 12:15 PM, João Távora wrote: > On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler wrote: > >> 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. > > Please, in the name of the sanity of this discussion, justify these two > statements with examples or follow them with a clause like "because...". João, I am giving hard examples here. What is not an example about "memory leak" or making debugging output verbose thanks to the attached string properties? You always repeat your demands but whatever I write it is not satisfactory for you. Is it possible to convince you? Can you try to interpret my arguments in a positive and constructive light somehow and fill them with meaning such that it makes sense to you? My goal is not to be right here just for the sake of being right. As Eli said, nobody has to prove anything. >> 3. The `completion-filter-completions` API is the fastest possible API > > Again that's quite a statement that I cannot evaluate the veracity of > without hard proof. As I said, I will ensure that my API does not introduce performance regressions. And since my new API performs strictly less work than your proposal it will necessarily be faster if you consider only the filtering, which is what matters for incrementally updating UIs. >> 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. > > Maybe they will, maybe they will. But it's still quite early to decide if > we're going to move all frontends to that API. There's no manual > documentation for it. Conceivably, if you appreciate your API so, you > could demonstrate in practice us how easy it is to use by providing > a separate patch that adapts icomplete-mode and fido-mode to use it. There is also no manual documentation of 'completion-all-completions'. Of course you are right that it is early to make these decisions, but the new API 'completion-filter-completions' is designed in a way to allow adoption by 'icomplete-mode'. It is important to design the API such that adoption is possible. I have a patch for Vertico which shows this. I can provide patches for 'icomplete-mode' separately later on. > In the meantime, there is a patch with a measured and documented > performance boost where fido-mode and icomplete-mode move > opt-in to a new `completion-lazy-hilit` feature in the "old" API with > a total or four 1-line changes. That patch lives in the branch > scratch/icomplete-lazy-highlight-attempt-2. As argued multiple times here now, the change you are proposing is fragile. It will lead to problems later on. The goal is not to find the smallest change which leads to a performance boost, all API violations allowed. Attaching "private" string properties to arbitrary strings is an API violation which we will regret later and which will make Emacs harder to debug and harder to use. > I think we should move to that, solving the bug#48841 while we > do the evaluation of all aspects of your contributions. No, we should not merge this problematic patch of yours. See the many arguments against this proposal. Daniel