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 16:15:22 +0200 Message-ID: <877dleb2px.fsf@posteo.net> References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <3ec7e2e58a100426a22e@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34714"; 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: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 07 16:45:27 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 1lU9Qr-0008py-1o for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 16:45:25 +0200 Original-Received: from localhost ([::1]:54604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lU9Qq-00031H-2v for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 10:45:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU9Pb-0001yS-EJ for emacs-devel@gnu.org; Wed, 07 Apr 2021 10:44:07 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:45959) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lU9PW-0003cz-FJ for emacs-devel@gnu.org; Wed, 07 Apr 2021 10:44:07 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id C5D7F2400E5 for ; Wed, 7 Apr 2021 16:43:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1617806637; bh=xxLp0a1G9i3pLKYV7qPB+ZdQtpMnAS5RUcLOHXLGX5A=; h=From:To:Cc:Subject:Date:From; b=XvLKWJB8hm4U5FcyGoNsdsMJuSWE2m41MsWBhJ0Og16mRqBGuMK45wUOEE+Q44MI/ hkk0yRDUQ1pI+UacnzlhQCF9kpO82eM5pp2zrF+a5N/mZGUj9pJCyIEo57HiRSCYbn NO40WdfuplQoNVnfAeU+qBxKXzfJ4FR/E4bzqxhuIsnN3bRWTXma5Vimx1CL6oT/6L mISbfyxPtFKM2W/q13URUTKEAHADIZGRLGXnVcyV+meLw1y320FyLk00IE+CpHfFcR WCe8YotA0s6RDmf4xNsg6aSpwE/nF5ki7yC7Uynt+ivBrtS5MwHHKTaqZNb2JFNdDv arx/giREZho6A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FFnG528WCz6tmH for ; Wed, 7 Apr 2021 16:43:57 +0200 (CEST) Resent-To: emacs-devel@gnu.org Resent-From: Philip Kaludercic Resent-Date: Wed, 07 Apr 2021 16:43:56 +0200 Resent-Message-ID: <87h7kiw3wz.fsf@posteo.net> In-Reply-To: <3ec7e2e58a100426a22e@heytings.org> (Gregory Heytings's message of "Wed, 07 Apr 2021 12:09:30 +0000") 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:267522 Archived-At: Gregory Heytings writes: >> I have the feeling all these completion systems are encouraging >> confusion around how to use completing-read. That is the 0th point >> that is missing here: Are you completing (expanding text) or >> selecting (narrowing options). >> > > I've been thinking about this, and I'm not sure I understand what the > real difference between "completing" and "selecting" is. Do I > understand correctly that the difference is between, for example, > expanding command names (completing), and choosing an emoji in a list > (selecting)? I think the main difference is in the UI. The default completion UI for Emacs will expand text in-place. M-x tdoe becomes toggle-debug-on-error, with the initials style. This appears to make sense for well structured text, such as commands or files. Selection are probably situations where you want more visual feedback, and it would make sense to present a list/tree by default. I don't think that this has to be strictly about text. Generally speaking, you can complete the textual representation of anything or select the object themselves. I don't think that either is always better, but I think we can do better than selecting textual representations. >> 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. >> > > Given that Emacs is primarily keyboard-driven, it seems to me that the > most efficient way to select an item is, and will always be, to use a > textual representation of the items in the list to select them. C-x 8 > RET does this, you (can) select an unicode character with its name. > For example C-x 8 RET inf RET inserts the infinity symbol. Or course > you could also navigate through the ~45000 unicode characters to > select the one you want, but that would be far less efficient. I don't think that something like selecting-read should just present a list of string. One might imagine using methods to allow an extensible way to control the presentation. Currently the standard procedure is to generate a collection and it's labels before passing it to completing-read. That's what insert-char does using ucs-names. I could imagine that selecting-read takes a list of characters, and uses a method to generate the textual representation of every entry. Ideally it could lazily only calculate those entries that are currently being displayed. By not limiting yourself to precomputed text, the interaction can also be improved. Taking insert-char as an example again, you might be interested in the kind of character data that C-u C-x = provides. That might just be a tab away. You might also be able to filter more effectively, by narrowing the selection based on such properties. 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. 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. -- Philip K.