From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#47711: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 15:58:47 +0300 Message-ID: <83h7fp8s1k.fsf@gnu.org> References: <837dgrdrec.fsf@gnu.org> <83mtpkbky3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14463"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, 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 15:00:56 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 1mFcEZ-0003TI-DV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 15:00:55 +0200 Original-Received: from localhost ([::1]:55978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFcEV-0008Pi-HE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 09:00:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43284) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFcDi-0008P7-GA for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 09:00:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37379) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFcDi-0004PH-8E for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 09:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFcDi-0002RT-6w for bug-gnu-emacs@gnu.org; Mon, 16 Aug 2021 09:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 13: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.16291187509294 (code B ref 47711); Mon, 16 Aug 2021 13:00:02 +0000 Original-Received: (at 47711) by debbugs.gnu.org; 16 Aug 2021 12:59:10 +0000 Original-Received: from localhost ([127.0.0.1]:48923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcCn-0002Pk-QH for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:59:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcCi-0002Ok-Hy; Mon, 16 Aug 2021 08:59:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47060) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFcCc-0004HU-LT; Mon, 16 Aug 2021 08:58:54 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFcCc-0006ac-7q; Mon, 16 Aug 2021 08:58:54 -0400 In-Reply-To: (message from Daniel Mendler on Mon, 16 Aug 2021 11:42:22 +0200) 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:212010 Archived-At: > Cc: joaotavora@gmail.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, > 48841@debbugs.gnu.org, 47711@debbugs.gnu.org > From: Daniel Mendler > Date: Mon, 16 Aug 2021 11:42:22 +0200 > > >> To address your technical comment - this variable is precisely what one > >> of the technical difficulties mentioned in my other mail is about. The > >> question is how we can retain backward compatibility of the completion > >> style 'all' functions, e.g., 'completion-basic-all-completions', while > >> still allowing the function to return the newly introduced alist format > >> with more data, which enables 'completion-filter-completions' to perform > >> the efficient deferred highlighting. > > > > I understand, but given that we provide this for other packages, it > > shouldn't be an internal variable. > > No, we explicitly don't provide this variable for other packages. It is > explicitly only meant to be used for the existing completion styles > emacs21, emacs22, basic, substring, partial-completion, initials and > flex to opt-in in a backward-compatible/calling convention preserving > way to the alist return format. The idea is to keep the existing APIs > fully backward compatible. > > Other packages should select the format returned from the completion > styles differently. They should return the alist format on Emacs 28 or > if the API 'completion-filter-completions' API is present. In the not so > near future external packages which support only Emacs 28 and upwards > will then only return the alist format and don't have to perform any > detection anymore. What if some package outside minibuffer.el will want to control the format of the returned value, for some reason, like support for old Emacs versions? are we going to disallow that? > >> The new API 'completion-filter-completions' will substitute the existing > >> API 'completion-all-completions'. > > > > That's your hope, and I understand. But we as a project didn't yet > > decide to deprecate the original APIs, so talking about superseding is > > premature. > > It is not the hope - it is the explicit goal. The API has been designed > to replace the existing API 'completion-all-completions'. A goal is not a fact. Until that goal is reached, we cannot in good faith tell people an API is superseded. > We can of > course tone this down. However I, as a package author, would appreciate > if Emacs tells me when a newer API aims to replace another API and when > the documentation is explicit about it. That's understood, and when we make that decision, we will of course announce it. But we didn't do so yet, and this discussion is not even about that decision. It could be, for example, that both APIs will live side by side until we decide whether to deprecate the old one. > Of course if you decide to have > the doc strings written in a different tone, I will adapt my patch > accordingly. Here I am just explaining why I chose the word "superseded" > instead of a more neutral word. I understand your motivation, I'm just saying that we cannot announce deprecation before we actually decide to deprecate. > > But the name says "filter completions". Which would mean you take a > > list of completions and filter out some of them. A completion table > > is much more general object than a list of strings. Thus, I think > > using "filter" here is sub-optimal. > > Okay, you are right about this. But I think even if the name > 'completion-filter-completions' is not 100% precise it still conveys > what the API is about. 'completion-completions-alist' or > 'completion-all-completions-as-alist' are valid names of course, but I > dislike them for their verbosity. Already 'completion-all-completions' > is quite verbose. A strong argument to use this long name is that the > completion style functions are still called > 'completion-basic-all-completions' etc. But if we accept that the new > API 'completion-filter-completions' will actually supersede the existing > API 'completion-all-completions' it makes sense to use a name which will > not hurt our eyes in the long run. However this is of course just a > personal preference of mine. I don't want to spent much time with name > bikeshedding discussions. If you decide on a name, I will adapt my patch > accordingly. Emacs is frequently accused in having names that are hard to discover. The only time where we can improve that is when a symbol is introduced, because later it's impossible for compatibility reasons. So I'd like to come up with a good name before we install the changes. That said, I'll let others chime in and agree or disagree with the name you've chosen. Thanks.