From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] `completing-read`: Add `group-function` support to completion metadata Date: Mon, 26 Apr 2021 00:50:37 +0300 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="9439"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Cc: Gregory Heytings , Stefan Monnier To: Daniel Mendler , "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 25 23:51:31 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 1lamf5-0002PH-QA for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 23:51:31 +0200 Original-Received: from localhost ([::1]:48936 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lamf4-0002bW-U3 for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 17:51:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lameK-00025x-LZ for emacs-devel@gnu.org; Sun, 25 Apr 2021 17:50:45 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:54084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lameH-0000WO-O1 for emacs-devel@gnu.org; Sun, 25 Apr 2021 17:50:44 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id i129so1940703wma.3 for ; Sun, 25 Apr 2021 14:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tszCAf052DeZYUc9wWzWh/weCYOlB/n6AmNicfaDc+U=; b=lDmAncK9xw2t3mjhHYCCTvL4zvI/2JK+ALH9znVnzUTfv3mcPtmN+EAuC0pV5m2JLZ fYklTXFON3mur33NvvGEcIXmM4pYFiOLkmXwptL84fVhTxPdR1xIs0elD04H99YSTBYp 2Xcj3uoFoqrcxhFzy0i+V07/rg/+kI2eCwg0V4o7eQUFCiSsYRsVXYIPWwCj4LN/UgcO +//ZVpvrtOfC2iZfepuWxeb6S87gHuSHe3DaP8KV3uk9YT5i8Rmgg+h1G3pDGihXUjLZ eAnlAnkHi83xSmoRbchqQzx/chuZMi2bnkSVPkxyl9uL1u7ALxdzaegWU2GYxdXHVbrG N0uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tszCAf052DeZYUc9wWzWh/weCYOlB/n6AmNicfaDc+U=; b=t8oB1+zLc0itLY1ESb8qtKMSaI1hzdxqoDiKXdbEGvxTKDPamT+V5oGJZBMN5E9X8G KmXONcTSP65TUOtHNgH1JggRIU0SY+G25QX3+iJNkkg8RyUAFD5q/ooPMJIked3Yyv0/ skvTn4OLNbMasf8HiFHiqmNCHTA5zaGV9BGNgctZFvgA11eZ2E88NqKwccvs2IUpRFkk jdOY1AQKiI194CU3RMUR+qwmKQcKnuq46BgNfaX72mIJweRlS7wQf2t6/zvGF9RdChJ8 Mw/m2jwk5KhIZc61M1niC1ZBkmes2ofsgIEr1jn/PCXG4XDTkotTHnPiB2BarylPOU+v 1OfQ== X-Gm-Message-State: AOAM530PPp56tl0s7cw2xoR9w6scDfV3XH5vz45KBrcD/40MPPf7hI5t qddFo4xoZ5LkHGkk6skW1Vo= X-Google-Smtp-Source: ABdhPJzPsnBYCV/oJ6WKmSz9CBMSjvsQ6pZfD2eUMN00jfe2Yxbcdtj+v0xCOQUPAtKDFL5F9cNsJg== X-Received: by 2002:a05:600c:1988:: with SMTP id t8mr16335877wmq.1.1619387439984; Sun, 25 Apr 2021 14:50:39 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y19sm17547033wmj.28.2021.04.25.14.50.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Apr 2021 14:50:39 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=raaahh@gmail.com; helo=mail-wm1-x334.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:268429 Archived-At: On 25.04.2021 22:47, Daniel Mendler wrote: > On 4/25/21 9:35 PM, Dmitry Gutov wrote: >> The result looks nice (when enabled), though this function still >> doesn't work very well with the default completing read. So whether >> this feature works okay will depend on the alternative UI used. > > Dmitry, thank you for looking at the patch! > > What do you mean exactly by "it does not work well"? 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. 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. 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. >> 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'd be curious to see some benchmark results for both versions. 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.