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 01:40:04 +0300 Message-ID: <23ebdd80-3ca2-4166-beab-e2535b6cc646@yandex.ru> 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="13440"; 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 Mon Apr 26 00:40:49 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 1lanQn-0003Om-8Z for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 00:40:49 +0200 Original-Received: from localhost ([::1]:58186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lanQm-0008TR-Cy for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 18:40:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60638) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lanQ9-0007wg-Sk for emacs-devel@gnu.org; Sun, 25 Apr 2021 18:40:09 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:37440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lanQ8-0004sT-7U for emacs-devel@gnu.org; Sun, 25 Apr 2021 18:40:09 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id l189-20020a1cbbc60000b0290140319ad207so1709312wmf.2 for ; Sun, 25 Apr 2021 15:40:07 -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=RCuU8JSaB6+WQR1umViX+/h3puSsOmK7JHD+iz87pRs=; b=bQF0nggY/FSm6FxdjA6ib210khcT1GhtN27lyQONOi1LeaqEnLisU2GmznbSTVwJBS XzsMR+5JLfYJ17epR2aIiUqjQLQzOKK/Foq7VcFfrSZ80F1NPpMj6Sh9UOHBE+q2dwAK a1ELxMvPfc+n+qLSNsxNUXWplBKWNDySyzxm7kjx/U6bEjDYm1rWf2qcvFMPdV3U5aFq Rbas7Sof1b3V/sxtZCe7DWwTMAjCb1Hv2wRNXNviWX8qK6N1ss+QdXXJzRqdC7aT4a29 kIjj69K54EGQSIe+nloHYLwYajlJWvXXR8/L9dElBGnm6ibDW7IThVKGRYBSuxJuGDv2 YZkw== 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=RCuU8JSaB6+WQR1umViX+/h3puSsOmK7JHD+iz87pRs=; b=pN6Nf9czoJONF5/yz+e7kkCP1+HIT7TIJ1pMlzv7+WUGJGJC7tRjkk4I6D6jXtOq6r 2B4cpIAAD8n0bqhomJmULrsL+sxZ8m59gvqaVC1wd1r1poTZ7dwtxYPd7vXCb49RAXN3 14r6ti5PavlxaptaozFvmpKyYhGlu7s6RszrAHGEMQVW/Y2lMVbdU8CoHqufWC8Vl8lG 8U8GUFeWKQgSGOZpFB/5vycg3lMy0htae3kLGnMU5Ngl54T4qrwuea6fDvXIFzKyhLTy IcWzDBZyeNvEOvZAj7HE7r0DDJrnCJhq3sKURAyBhf+VFlmWIaTsYQhfTSuKZGeTwtZo INgg== X-Gm-Message-State: AOAM532inzFDcaARsN9mxE10BZZd89YrBABOYALLyJNB1j5sh9vgSMrg VDr9xp6EcHtmc3oRRAhmUh+8MuogcCw= X-Google-Smtp-Source: ABdhPJyKV92MY2PH/ZtQqxHL1WxiCnxJvDAQih2n8ibBbXJH8lEESQXnlmQgwZBxuDDBkfOBT3k3aQ== X-Received: by 2002:a7b:cc11:: with SMTP id f17mr16680402wmh.159.1619390406736; Sun, 25 Apr 2021 15:40:06 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b12sm19938458wrn.18.2021.04.25.15.40.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Apr 2021 15:40:06 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32e.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:268433 Archived-At: On 26.04.2021 01:10, Daniel Mendler wrote: > 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? It doesn't work as well with default UI because you don't see the options without pressing TAB, and you don't know what to type. Paraphrasing the words of our maintainer, completion is for when you know what to type, just to be able to do it quickly. And (as might be summed up from the same recent discussion) what that completion table needs is "selection". So it's better if at least icomplete-mode is enabled, preferably with an option which shows the completions right away with no input. And the vertical style should be even better. >> 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. Helm and Consult use it mostly for sources which return some sort of "matches" from a Grep-like program, right? Lots of matches, none of them knowable in advance? Stock Emacs usually uses a buffer for that use case (like M-x rgrep). >> 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. That's a valid argument too, of course. >> 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. OK, I see. So you fuzzy-match it on the client, if the user types further characters to narrow down the search.