From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico Date: Wed, 07 Apr 2021 09:02:49 -0700 Message-ID: <87a6qakrpy.fsf@ericabrahamsen.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="13208"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Philip Kaludercic , "T.V Raman" , Manuel Uberti , 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 18:05:09 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 1lUAfy-0003F3-UK for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 18:05:06 +0200 Original-Received: from localhost ([::1]:45652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUAfx-0006lt-VN for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 12:05:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUAe0-0004vW-E8 for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:03:04 -0400 Original-Received: from ericabrahamsen.net ([52.70.2.18]:45414 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUAdy-0002rI-D0 for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:03:04 -0400 Original-Received: from localhost (nat-out-5.ykwc.net [199.68.205.5]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 64D70FA099; Wed, 7 Apr 2021 16:02:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1617811373; bh=GLr+1hCaGtCyuMdI7iNkDhrXtflLXmCzmbfe0p/ilCk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=x2XLAy61KYw5ydnsVA2bhmmFB7BUHDmCJbZA8mQz9W2wuGB2DbRGEJAEv0cGvjpup 6SepaE+IPfeeXv4xbFZbocv0zTTNXTAD41+Ehv66CJbaOjaxHzmcJ0CoXRO5MNke2z dd2nTdClQr9V1skNErP+tivqfUuCYBIYsQLKFMOs= In-Reply-To: <3ec7e2e58a100426a22e@heytings.org> (Gregory Heytings's message of "Wed, 07 Apr 2021 12:09:30 +0000") Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_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:267528 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)? "Completing" is "help me make this string longer based on available options" and "selecting" is "choose one of these things". Yes, they're often collapsed into one, but they don't *have* to be, for one thing, and for another I was thinking about this more in terms of developer convenience than making some revolutionary change to the UI. We've all written this a million times: (let* ((choices (mapcar (lambda (elt) (cons (make-string-from-thing elt) elt)) my-list-of-things)) (choice (completing-read "Choose: " choices))) (cdr (assoc-string choice choices))) If we put a little work into refactoring, and make a `selecting-read' function that accepts a few other functions for doing the actual selections, then why _not_ allow choosing from a list by number key, or character key? Or for small collections, simply C-f/C-b and then RET? Or cycling through a collection of buffers, displaying one buffer per second, and letting the user hit RET when they see the one they want? Okay that sounds awful, but flexibility is good. I find myself wanting/needing to tailor the actual strings I produce for collections based on the completion framework in use (ie what works well for Helm feels awkward in Ivy, or in vanilla completion). That seems wrong. Anyway, that was my take on a discussion that didn't originally have anything to do with me! Eric