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, 07 Apr 2021 18:20:55 +0200 Message-ID: <87blaq5amw.fsf@posteo.net> 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="2575"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (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:26:46 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 1lUB0v-0000Wu-Vk for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 18:26:45 +0200 Original-Received: from localhost ([::1]:42948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUB0u-00035X-Ua for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 12:26:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUAvS-0007jv-9q for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:21:10 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:45141) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUAvM-0002pF-Uj for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:21:05 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id D23CC240101 for ; Wed, 7 Apr 2021 18:20:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1617812456; bh=I9gr8M4nW96oWBkqU5fa69K0NXmniEp0X2mci2v/jJA=; h=From:To:Cc:Subject:Date:From; b=Orl2HvVGuXvMtW/mi+GZcEMZVeZ47DripQudnY4/gueHC6cPY1lT463ZGHjq+LDFt zMOZUerlRaHalXHm7aJk7yGPcRn5RQ42yZM7yu+HOzsCDVSNXRewsmm02kvipiGAqS f1d2y673u55Z3Ug/UzR+DgsNGeDWywFBb98CKjcOuPAIvgLL/FzS73CI9vM21IsYB6 GIURe5lbFPQQRqRo7Z7MuzpA3FXX8EQEwSVOj8+Lo+88sUbQ+hO5KyLYnQ8133qgm1 qR5zIZ9xHrEBKAxQph9v10cLwyVpRuoVvTqza9vgfmihaK8RlJ1YlHfv0YWOH0j+00 C+NMtg/nUOxvw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FFqPz64WXz9rxT; Wed, 7 Apr 2021 18:20:55 +0200 (CEST) In-Reply-To: (Daniel Mendler's message of "Wed, 7 Apr 2021 17:17:07 +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:267533 Archived-At: Daniel Mendler writes: > On 4/7/21 4:15 PM, Philip Kaludercic wrote: >> 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. Well that is because imenu presents the options in the minibuffer, and you have to go through the menu step-by-step. What I'm talking about is a direct hierarchical visualisation, that should be navigable with the intuitiveness of org-mode. >> All of these features already exist, partially or only to the degree it >> is found to be necessary. Eg. ibuffer has hierarchies and the ability to >> filter by some preconfigured predicates. I think that there is a general >> pattern here that can be exploited to make the overall experience more >> uniform. > > 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'. I don't think that selecting-read should replace completing-read. Rather there are cases where completing-read is used like selecting-read, that would profit from actually being selected by everyone, and not just those who use completion frameworks that interpret completion as selection. > Regarding predicates, there is an idea how this could be integrated > with completion. One can implement a completion style which support a > filter language, depending on the completion category. The completion > style can then execute the filter predicates on the corresponding > objects. However such an approach certainly takes it a bit far as > completion styles are concerned. I think Icicles offers options to > filter within completion based on predicates? I think there is more value in keeping completing-read simple, and focus it on actual text expansion. Completing-read will probably never really be overcome, just because there will always be software that continues to use it. In some sense the abundance of solutions around completion show that the community wants something else than what completing-read provides by default. I get why, as a lot of packages use completing-read. But it might be better to start from the position we want to achieve, instead of hacking our way towards that end. > Daniel Mendler > > -- Philip K.