From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Improvement proposals for `completing-read' Date: Thu, 08 Apr 2021 10:44:57 -0400 Message-ID: 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24051"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 16:48:41 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 1lUVxZ-00069s-LM for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 16:48:41 +0200 Original-Received: from localhost ([::1]:41784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUVxY-0005wa-Mz for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 10:48:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUVu6-0004G1-Sc for emacs-devel@gnu.org; Thu, 08 Apr 2021 10:45:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30788) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUVu2-0003br-Ag for emacs-devel@gnu.org; Thu, 08 Apr 2021 10:45:06 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C33C510020E; Thu, 8 Apr 2021 10:44:59 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 65B1E1000F4; Thu, 8 Apr 2021 10:44:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1617893098; bh=Z5Iz2xOnOLXK3rJPf3U13UHdlIIAQEqX/Kev5ZRMjPo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dtlmCSR/xJg3yargYRqeSaij0cJyxbU9seuacRJHVoY4frJV91UdB0eZSBUkBDgny E7A9lR4WKtG91AzrjH8ojBCFFoCt6TQtGx2kd/CKUtr3MU7jTaqHSBjvsg5YeXrzT9 GIKtPW//EWSB3hd6lKsJ/0FC1599D2Sd5x1HUbSlNtaTVl7SSEjgyBpM4/W0c1Z02D IoV8Ylclgm6RqSZr10uya70WBYncuj87SLm0JctBt0oZvZ8XBUui59P6BiuxA+27wm DvHb22rC32e5O4Mti/rs7W1o4lIOEz39kNzxlBHB0AuEIEx29j5CN+2Yl3b3/cCXU7 +lhYL4lOdkLfw== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D5CCB12022D; Thu, 8 Apr 2021 10:44:57 -0400 (EDT) In-Reply-To: <264397e8-5a03-9eff-436c-639d76514775@daniel-mendler.de> (Daniel Mendler's message of "Thu, 8 Apr 2021 11:01:42 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:267616 Archived-At: > I would also like if `completing-read` is consistent with > `read-from-minibuffer` in this case, since this lead to actual > confusion, where the false assumption has been made that > `completing-read` also accepts `t`. No objection from me (the discussion was more because I was curious ab out the motivation for the change). > Maybe we will see the orderless package in ELPA at some point. It's already in ELPA (more specifically in the MELPA archive). But I hope it will appear in GNU ELPA, indeed. >> 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. 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. > 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 would therefore go with the simple solution first since this > provable solves the issue. Yes, the "skip-highlights" approach is a good solution for now. The one I discuss above requires a whole new API, so it's just hotair right now. Stefan