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.devel Subject: Re: complexity in minibuffer Date: Wed, 2 Jun 2021 17:53:14 +0200 Message-ID: <618fccff-fbf9-74d8-d4e6-2f28c3d16702@daniel-mendler.de> References: <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <875yyxaoxp.fsf@gmail.com> <871r9laj6a.fsf@gmail.com> <1b73a130-204c-76fb-2b60-02b814aee0f0@daniel-mendler.de> <87r1hl8xom.fsf@gmail.com> <878s3t8tzw.fsf@gmail.com> <3c68bd00-70ca-fa18-f9b8-cd03029f9294@daniel-mendler.de> <8735u18lsd.fsf@gmail.com> <8e33bbfe-0015-b85c-b57c-ba448f2e6215@yandex.ru> <3d519805-f602-fa52-ec69-0506bb6cb568@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19539"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , "emacs-devel@gnu.org" , Dmitry Gutov To: Stefan Monnier , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 17:54:29 2021 Return-path: Envelope-to: ged-emacs-devel@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 1loTCN-0004ho-UU for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 17:54:27 +0200 Original-Received: from localhost ([::1]:60488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loTCM-0000Sn-PP for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 11:54:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loTBO-0007Rl-Bi for emacs-devel@gnu.org; Wed, 02 Jun 2021 11:53:26 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:36111 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loTBH-0002IH-JI for emacs-devel@gnu.org; Wed, 02 Jun 2021 11:53:25 -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:References:Cc:To:Subject:From: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=gdR3InuuyMAyPFHO8MjyTGDZWdqSIyVm4bSidtTsxRQ=; b=MoIYRLPxib+7CE0295yZACSSo7 V/rKUNYpT9HvWnuyHwJVI3d/8SJhqe1W6RlTtK02LvG2VcqjE/ZZbhH5WvYGZP2Ig7zxXrNCssnCJ LqJvFXk5Ro8s2IC4tkLy9QsIKh7kdsEmy1A9NJK1B8cDUv1EMLopsv78+OHyWc6uXX0k=; In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270308 Archived-At: On 6/2/21 5:38 PM, Stefan Monnier wrote: >> By that time, you have already traversed the completion list many times. >> What's the problem with having the completions themselves contain >> all that's needed to render them? > > If you have 10K completions, the time need to compute their rendering > becomes very significant, so we want to only compute the rendering for > those completion which actually reach the glass. Yes, it is crucial to only compute annotations/affixations/group-transformed-candidates only for the visible candidates, since all these computations may be expensive. I think we should make this part of the `completing-read` definition, that these functions are allowed to do more expensive work, since they are always called on a small subset of candidates, which are going to be displayed. >>> I don't have a strong opinion here, except that I think it would make >>> sense to handle `group-function` and `annotation/affixation-function` at >>> the same place. >> You do have to call the first on all of the completions and the latter only >> on a subset to be displayed. That's a constraint of the problem itself. > > Not necessarily: you could also decide to only group those completions > which are displayed. For the default completion UI this is the case. But this is not how grouping works for UIs like Vertico, Selectrum and Icomplete-vertical, where the first grouping step has to happen after sorting on all candidates. The grouping candidate transformation can then come later only for the visible candidates and can then be comparatively more expensive. Daniel