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: [PATCH] `completing-read`: Add `group-function` support to completion metadata Date: Mon, 26 Apr 2021 00:10:38 +0200 Message-ID: References: <39c93100-a352-538d-717a-663bcc5de296@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12880"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gregory Heytings , Stefan Monnier To: Dmitry Gutov , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 26 00:11:45 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 1lamyf-0003HX-Ic for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 00:11:45 +0200 Original-Received: from localhost ([::1]:53196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lamye-0005EC-Ls for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 18:11:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lamxj-0004mS-Fa for emacs-devel@gnu.org; Sun, 25 Apr 2021 18:10:47 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:35401 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 1lamxg-00045v-Ot for emacs-devel@gnu.org; Sun, 25 Apr 2021 18:10:46 -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=bttI9a9CgwP/HKrgNPxjEINdgbUJjUwvsfKyNOcH5JY=; b=acMevG1+Kld+fzNv7QQsoejCsv i1yu0cxF7yf5W0xrR/IgfJum3Zx4y9WYqz2+G0TTQPPz0nG0wavO0Q0LXua5jrNVL8ZX0ndckZ8PY 7s3HPxVPA2C+5F56WqK8Ip4xihtMBSJvF0pP260AUyB+InGmMfNP1ZcvyL4bPhiV0MOo=; 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:268431 Archived-At: On 4/25/21 11:50 PM, Dmitry Gutov wrote: > Sorry, I was basically referring to an earlier discussions where the > consensus was that xref-show-definitions-completiong-read doesn't play > very well with the default completing-read. Its completion table is odd, > one could say. The proposed feature simply doesn't change that. I understand. But in which way do you think the function `xref-show-definitions-completiong-read` is odd? If you use completion styles like `flex` or `orderless` you can quickly narrow down the number of candidates and select. It works well for me and the grouping makes the view more clear. > Perhaps if all currently planned uses of group-function are similarly > "odd" (and no additional uses in the core are going to be added in the > foreseeable future), you don't need to worry/care about having > :group-function added to the core, or at least not yet. Or about > updating the *Completions* UI. I assume there are more commands in Emacs where grouping functionality is useful. Grouping is heavily used in Helm and in my Consult package, so having such functionality officially present in Emacs is certainly valuable. > And keep it like "unofficial extension", which I'll be happy to support > in Xref anyway (and Xref is in ELPA Core, so users will always be able > to install the latest version). There are benefits to being such > extension: once you're a proper part of the protocol, you become much > more set in stone. Yes, this would be the most minimal change - only define `group-function` as an official metadata which can then be used by commands and UIs which support it. However it would certainly be more encouraging to make use of the functionality if thereis support in the default completion UI or Icomplete. >>> Speaking of group-function's implementation there, the >>> text-properties approach seems like an overkill since we can reliably >>> string-match anyway. But it's a minor thing. >> >> I've chosen the text property approach such that the group title >> retrieval does not lead to allocations (transform=nil). The >> transform=nil call is performance critical for continuously updating >> UIs like Icomplete, Vertico etc., since the candidates are grouped >> after sorting. > > But when the list is updated, the elements are basically recreated from > the external process's output every time, right? So this only helps if > you want to cache the result for repeated invocations of group-function > on the same result set. I am not entirely sure I understand you correctly here. The candidate set is generated once from the external process. Then the properties are attached once per candidate. In the subsequent filtering/completing of the candidates, the candidate set and the attached properties are *not* regenerated. This means we save a lot of work here. In particular with continuously updating UIs we avoid regenerating the properties every key press. > Also, xref-find-definitions usually deals with a limited number of > search results. But I guess some of your users set > xref-show-xrefs-function to xref-show-definitions-completiong-read too. Yes, this the use case I proposed. Then you can have many more candidates. Daniel