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: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico Date: Wed, 07 Apr 2021 12:14:30 -0400 Message-ID: References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <3ec7e2e58a100426a22e@heytings.org> <877dleb2px.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37113"; 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 Wed Apr 07 18:17:13 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 1lUArg-0009QH-6N for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 18:17:12 +0200 Original-Received: from localhost ([::1]:56656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUArf-0004Fi-8U for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 12:17:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUApI-00034k-Nf for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:14:44 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44508) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUApF-0008HO-D3 for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:14:43 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 199EC10020E; Wed, 7 Apr 2021 12:14:40 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 813E91000F4; Wed, 7 Apr 2021 12:14:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1617812078; bh=l2x0wjgoLM0DMMtZCy2owkpqhG6cVazBtpLB4bmLAK4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=lMxno1GbuHb8sBcXZzdpXC1k6JbKudqNRXqNxz6krARvmMEnujGwungPUt46m1poO 5V6IygerIz7oq6V2ccER+a1+fhPhrTGrSK0UTEz2WFJ4qf3ZnGU5zh/AvGIF2IkEhS M4KOA2eDyV2PcO0Mh8RG/YjJGXepLYnrN0vE+a0y12jMYLwAUVhjvnX+yw8sd6Sidd SbdBvAuhD6W8f+vn8RabbkoDR43sjLRY8WBDm2RpnkGaR7NKLDYngDEjBy1k/b08Gi pATuRSozZf84Manma4XM1zATJtspiCeqcvDobZKxnIvzVYMlS/Chc1zCjrfFjtjAih mp0MPxuGy2/kw== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0DCFE120186; Wed, 7 Apr 2021 12:14:38 -0400 (EDT) In-Reply-To: (Daniel Mendler's message of "Wed, 7 Apr 2021 17:17:07 +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:267531 Archived-At: >> I think I've also mentioned that selection can be hierarchical. I think >> this too would be applicable to insert-char, considering how unicode >> divided into groups and subgroups. > > I agree that hierarchical selection can be useful when browsing through > a structure. However when doing a quick selection, I perceive it as > slower. For example there is imenu, where you have to step through multiple > layers of the hierarchy to reach the destination. A popular demand is for > a flattened imenu which allows faster completion, see for example the > package flimenu or counsel-imenu. But as soon as you flatten you certainly > use the ability to browse the structure, so you have some point. [ I like `completing-read`-based selection, so the below is written from that point of view, but I agree with Philip that it's important to design the API so that other UIs can also be used. ] For imenu, it makes sense to be able to say "v/foo" to select that variable "foo", but also to just say "foo" when you don't want to bother stating the category (because presumably there's only one "foo" anyway). It would also make sense to complete unicode char names with extra constraints like "s=foo bar" to get the chars whose name matches "bar" and whose script matches "foo". > I wonder how all these use cases could be unified under a common > API. I would certainly not want to lose the current fast, flat selection > mechanism via completion as offered by `completing-read'. Maybe we could add methods to completion tables that return the set of "characteristics" that can be used to filter, others that list the set of possible values of those characteristics, etc... Stefan