From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico Date: Wed, 21 Apr 2021 14:21:01 +0000 Message-ID: <87tunzafci.fsf@posteo.net> References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <87blamp5hy.fsf@posteo.net> <87h7k0c7tz.fsf@posteo.net> <6208c85a-0127-218e-607d-cd4a6dd219ec@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="33609"; mail-complaints-to="usenet@ciao.gmane.io" 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 21 16:21:53 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 1lZDjl-0008d9-MV for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Apr 2021 16:21:53 +0200 Original-Received: from localhost ([::1]:54798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZDjk-0001Io-Nh for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Apr 2021 10:21:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48046) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZDj7-0000sx-OX for emacs-devel@gnu.org; Wed, 21 Apr 2021 10:21:14 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:42009) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZDj1-0001cH-M8 for emacs-devel@gnu.org; Wed, 21 Apr 2021 10:21:13 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id C2C682400FD for ; Wed, 21 Apr 2021 16:21:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1619014862; bh=wf5JOzC60h31FrdZMLtqZQ9UCj94KLShco1qHpDPKV4=; h=From:To:Cc:Subject:Date:From; b=gdxDx//2MX+/YwTPAeWpesKHN1eKjaq3uPWT4QTDPvXqRxtE6c8gZze5qcDuGY225 28sN+1tieW9KRn0S+r8cf8Neudxd/mVVDK62aOoMyqxFnr6ZUg+TKAtffLPQeAyWLi nQ8R+6jJbeYsSXTFsHArUkSv+0B/d8r8is/qKJgL9cykTEAXySgcn7pNrLE8prxqub 5eGK12RFJihePvK2CbTMPPkksy1dD68uF9dI2n69t+tT/2furUM1WNTwOVUd1N1Zk8 rbNtppsxsuRmJZNOXUlU/F2iV6LoeHofnKfaJK2+j0cwNr7/CFzG9VEPIT3Ih5cqmG VnCA1WJUeT7hw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FQN5B0Ypbz9rxB; Wed, 21 Apr 2021 16:21:02 +0200 (CEST) In-Reply-To: <6208c85a-0127-218e-607d-cd4a6dd219ec@daniel-mendler.de> (Daniel Mendler's message of "Wed, 21 Apr 2021 15:14:39 +0200") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:268233 Archived-At: Daniel Mendler writes: > On 4/21/21 11:20 AM, Philip Kaludercic wrote: >>>> It might therefore be necessary to actually implement a "selecting-read" >>>> function, that could be used more or less like completing-read, but that >>>> provides a better default UI not based around completing text but >>>> actually selecting objects/items. >>> >>> I attached a primitive version of selecting-read to this message. The UI >>> is horridly primitive, but the basic idea should be understandable. >> >> Here is an updated version, not with improved visuals: > > I think it is interesting to experiment with actual use cases. Maybe > it is a good demonstration to write a `read-buffer-function` and a > `read-file-function` based on such a `selecting-read` API? The buffer > selector is not hierarchical (at least as long as one leaves out > perspectives or other levels), but there can be properties for > filtering. In the case of the file selector one can experiment with > hierarchical objects, and dynamic generation of the object > tree. Partial-completion/initials can be used to filter/restrict the > hierarchy. I will try to look into this as practical examples, after the performance has been improved and the query language is more than just regular expressions. It hope that it would demonstrate limitations of the current interface. > As with `completing-read` it should be possible to decouple the > components in ui, filtering language and backend/object > representation. Of course, the current implementation also provides this with the generic functions on the one side and selecting-read-function on the other. The current UI is pretty hacky, so I'd expect people with more experience and enthusiasm when it comes to come up with better solutions. >> I have also mentioned that a "translation function" could be written to >> translate completing-read calls into selecting-read. Here is an example >> that could be set to completing-read-function, even if it does not >> implement the entire interface: > > This translation function implements only a small part of the > `completing-read` interface (static completion tables). Did you look > into how dynamic tables could be supported? Or is this something you > would rather leave out to introduce a separation of `completing-read` > and `selecting-read`? Separating the completion and selection use case > may be technically cleaner. Going with a unified API could lead to a > more consistent system overall? The translation function is currently more of a POC, as there were some messages on that topic in previous thread. It is entirely debatable if selecting-read should provide a super-set of features that completing-read provides, or it should just have an intersection. I haven never really used dynamic tables for completing-read, so I'll have to look into that and see how it might apply to selecting-read, if at all. > Daniel > > -- Philip K.