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: Improvement proposals for `completing-read' Date: Thu, 8 Apr 2021 17:37:39 +0200 Message-ID: <82c86e8f-06e7-a7ed-56c5-5f6766df591b@daniel-mendler.de> References: <0342c2d5-02dd-ad9e-5b8e-dfe52f6469c6@daniel-mendler.de> <264397e8-5a03-9eff-436c-639d76514775@daniel-mendler.de> 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="16679"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 17:38:58 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 1lUWkE-0004D7-Iy for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 17:38:58 +0200 Original-Received: from localhost ([::1]:36174 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUWkD-0005mC-Hj for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 11:38:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35002) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUWjM-0005H0-JW for emacs-devel@gnu.org; Thu, 08 Apr 2021 11:38:04 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:59583 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 1lUWjI-00025X-SG for emacs-devel@gnu.org; Thu, 08 Apr 2021 11:38:04 -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:To:Subject:Sender:Reply-To:Cc: 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=UuKj6tvopihMgpQ39KiI2wHCqs01FnWESpjvkYpZynM=; b=JOIpf+mw054c5E7rrfQcgkuuuu uJGoQxCFj6tQDott4cy8t/bF9sVVMK9YR8u4KYwboPIsX50JZrXPpAL4NprSlTWG4ZEMazwAFlJ31 jAvbJH30t54E2I44UHDb7XU3gTZS86XA5ef7DEqSvK5D/TBCb6wjC1glTqAWqF+n1ms4=; 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:267624 Archived-At: On 4/8/21 4:44 PM, Stefan Monnier wrote: >>> As long as we can offer some way (that's not too cumbersome) to select >>> between the different cases using things like self-insert-command + RET, >>> I'm fine with it. IOW I think it require reifying the "subtle >>> differences" as some kind of optional extra text. >> Okay, maybe I can come up with something. This will require >> experimentation. The duplicates could be deduplicated at the UI level by >> appending some index for example "candidate (1)", "candidate (2)", ... > > I think we should arrange for the completion table to provide that extra > text, so it can be more meaningful than an arbitrary number. Also the > user needs to be able to know "which is which", so it needs to be > connected to something that's displayed in *Completions* that > distinguishes them. Yes, that would be the best possibility. There are many ways to provide that data: Via a text property, via an extra metadata function, etc. In the case of Swiper the extra data could simply be the line number. However a general solution should also automatically generate indices, since it is probably better to not require the completion table to provide the information in any case. I would like some graceful degradation. > E.g. maybe we could arrange for the minibuffer text to be > matched against the *annotated* candidates in some cases. I think this > requires more thought, together with concrete examples. Generally matching against annotations functions is problematic. As I interpret things, the point of annotations is that they are not matchable. Maybe they are more expensive to compute, so this should happen lazily for the displayed candidates. But using it only for disambiguation should be okay. Then one would only compute the annotation when doing the actual completion? >> One thing to consider - maybe returning the highlights as some extra data is >> not actually faster than simply propertizing the strings? > > The extra opaque data is cheap/free to compute. It would not contain > "the highlights", but just the side information that might be needed to > compute the highlights: e.g. you can't do the highlighting correctly for > `partial-completion` without having access to the "pattern" against > which it was matches. I don't think this is true. At least not for the orderless style. There the pattern compiler compiles the input to the `completion-regexp-list`. This is fast for filtering but there is no way to obtain the highlights directly as far as I see it. Then in order to compute the highlights the highlighter once again has to receive the input pattern, generate the regexps and match them one by one, adding some faces to the strings. Daniel