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#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 13:17:56 +0100 Message-ID: References: <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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8852"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , 47711@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 14:19:29 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 1mFbaT-00027S-52 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 14:19:29 +0200 Original-Received: from localhost ([::1]:53438 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbaQ-00014U-1w for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 08:19:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFba2-00013A-Gn for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:19:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37265) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFba2-0002S5-9l for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFba2-0005QM-5r for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 08:19: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 12:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911629720777 (code B ref 48841); Mon, 16 Aug 2021 12:19:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:18:17 +0000 Original-Received: from localhost ([127.0.0.1]:48810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbZI-0005Oy-QN for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:18:17 -0400 Original-Received: from mail-pj1-f48.google.com ([209.85.216.48]:46021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbZG-0005Oc-4H; Mon, 16 Aug 2021 08:18:15 -0400 Original-Received: by mail-pj1-f48.google.com with SMTP id m24-20020a17090a7f98b0290178b1a81700so27283048pjl.4; Mon, 16 Aug 2021 05:18:14 -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=vG3PtNb8GFe1kTTcPbNe6NfvS5vc+wIhZ/FWyFFtPIA=; b=aSH3HPLhgEj06AokK9atlnXYm/oOd2CjowEF2KvMYq4OxnlLlxnOcYegTgcjSZrUir /Gnqd2IF3JkQsi/P7PDf9sWksjDdJqDcCCOlCJwSJz6tfBtT42fLgRGpo8Bie73KkyEY 3sMa17mBF5tUc4naAeibyvCC4I3vNffSI6++HNQ06W0LODRwswVIMbL/rNCRtMBs4QiP baMmFVNDsnxePgBeGwjgxaerbmFFBAMcb9rqwdLxml5NldIlSBq+0XMr7zorhL6OVPnM CwwKcY4cmbR5IHmKB0AVp2KVJ3ijYxFih/1F43g9ExDOg90vYdFXBYhMNmAr8mZZHUaz ZJBg== 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=vG3PtNb8GFe1kTTcPbNe6NfvS5vc+wIhZ/FWyFFtPIA=; b=Qom4B1JVd2ZKFouUGQ25Szzp34t2JSAqbsBlhonSin5uEhbqc1uyLEuaiu1uiyTGQk sN4Oa+ujRE6TlkJbeChFQEEcarV2LlcTHVkRQ8oIUgh3eH/Sc+a7l5UnBXcAHd3cbLqN hoM25UtCRLfVHM5Lpb8TC7kH9G0DMLh/fCZJf3YLaqUm77Wb+NQ7Ikd88zGsnOZHKnv0 tlcz2WZgiqa06Pbp4DHpPbXpk+lAdmYi64078Vt4JITHGNohBjLQHWJ+vMRwalfWVM7H Cwy8hCHbBsTnf7KKBq7NQAgDWAo6PdLI8rqP4I7BPQn0GvjtrQN+VOUNp7S8p2A77m4G ELJQ== X-Gm-Message-State: AOAM530uHOE8XO7G+R8t3gJtzl2uHZn12DE1K2XH0w6nt4F7tKoRPqi0 +O00AgqYEN4BLhgsPbqsZUPT5S+rqrlkfgWlrfw= X-Google-Smtp-Source: ABdhPJywkcSc4K1vtg2RIk7Im7oLva1pYFsW7yZevcSSbs8sdCdSVuP1J3zmP4M1vGwMvMjrDIjDcCGF+zSjKJ/4/lQ= X-Received: by 2002:a17:90a:3849:: with SMTP id l9mr6083033pjf.7.1629116288241; Mon, 16 Aug 2021 05:18:08 -0700 (PDT) In-Reply-To: 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:211999 Archived-At: > Jo=C3=A3o, please feel free to also present your closing arguments here. Sorry, I don't "close" arguments like this. I hope you can provide: * the fixes to the regression identified * the benchmarks you say you have * the patches to icomplete.el that show how it uses your new API * the demonstrations of the bugs you accuse my patch to suffer from Thanks. On Mon, Aug 16, 2021 at 1:05 PM Daniel Mendler wro= te: > > Jo=C3=A3o, the discussion is clearly not progressing. I propose that we b= oth > take a step back and let the Emacs maintainers, who participated in this > discussion, decide on how to proceed. It seems to me that all arguments > and data has been presented and there is no need for further > reiterations in more and more colorful language. I would also like to > point out that implying that I don't understand your language is > borderline acceptable. I understand the discussion very well, but I > don't understand why you are using these unfair and invalid means of > discussion. > > For example there could be these decision outcomes: > > 1. The information presented up to now does not allow the maintainers to > make a decision. For example the maintainers may ask for further > clarification from you, Jo=C3=A3o, or they may ask for benchmarks from me= or > a prove that my patch does not lead to performance regressions. > > 2. The maintainers decide that no patch should be merged. > > 2. The maintainers decide that your patch will be merged. I will accept > this decision. > > 3. The maintainers decide that my patch will be merged. You will accept > this decision. > > 4. The maintainers decide that both patches will be merged such that > both approaches will be supported. We both will accept this decision. > > I want to summarize the situation in the following: > > The patches in question address a performance issue in the current > completion machinery which is caused by over-eager copying of the > completion candidate strings and over-eager application of the > highlighting to all candidate strings. For incrementally updating UIs it > would be sufficient to only copy and highlight the strings which are > actually going to be displayed. > > My patch takes the approach to expose the existing two-step completion > process, which consists of filtering and highlighting. By returning the > filtered completion strings and a highlighting function this two-step > process is decomposed and the caller of the API has the ability to call > the highlighting function on only the displayed subset of completion > candidates. I argue that exposing the filtering and highlighting > procession steps is the logical and natural conclusion of the existing > machinery. > > My patch is fully backward compatible and aims to not introduce any > regressions (also no performance regressions) to the existing API. > Furthermore my patch adheres to the current guarantees given by the > existing 'completion-all-completions' API. The completion strings > provided by the completion backend are not mutated in any way, no string > properties are attached. Since the API 'completion-filter-completions' > proposed in my patch does the minimal amount of work necessary (only > filtering), if no highlighting is requested, I argue that the new API is > the most efficient possible API, given the current constraints. > > Furthermore since I am introducing a new API, outstanding issues can be > solved which could not be solved until now given the constraints of the > existing 'completion-all-completions' API. In particular the new API > 'completion-filter-completions' API returns additional data like the end > position of the completion boundaries. Until now the end position was > not made available and 'completion-base-position' just used the length > of the input to guess the end position. In a strict sense this guess is > incorrect and there is a FIXME in minibuffer.el, mentioning this issue. > > The downside of my patch is that it is a large patch. While it adds only > 196 lines of code, which is not much and expected given that it only > reshuffles the existing machinery, it is still a large patch in total. > > On the other side, Jo=C3=A3o's patch avoids the complication of adhering = to > the existing guarantees of the APIs and takes the liberty of attaching > "private" string properties to the completion strings of the completion > table backend. I argue that attaching the string properties is a > violation of the guarantees of the existing API and violates the > expectations of the existing many completion tables. One very severe > scenario is when obarray is used as completion table, since then each > symbol name gets a private property attached. I argue that such global > side effects like attaching string properties to all completion > candidates should better be avoided. There is the issue that the > attached string properties are a potential memory leak. When dumping the > string representation of symbol names, the symbols will have additional > properties which will complicate the debugging experience. Furthermore > it will lead to confusion since the global side effect during completion > will suddenly have an influence of symbols which don't have to do > anything with completion. The big advantage of Jo=C3=A3o's patch is that = it > is very limited in scope and very simple. However I argue that this > simplicity is hard-won and we will regret this approach later due to the > global side effects. > > Therefore I conclude that the two-step process proposed in my patch, > which does not introduce problematic global side effects is the better > approach forward. Furthermore a new API is needed such that more > completion data can be returned, e.g., the completion end position. One > could even return additional match data in the future given that the new > API 'completion-filter-completions' is extensible thanks to its alist > return value. > > Jo=C3=A3o, please feel free to also present your closing arguments here. > > Daniel --=20 Jo=C3=A3o T=C3=A1vora