From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico Date: Wed, 21 Apr 2021 15:14:39 +0200 Message-ID: <6208c85a-0127-218e-607d-cd4a6dd219ec@daniel-mendler.de> References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <87blamp5hy.fsf@posteo.net> <87h7k0c7tz.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3971"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 21 15:16:37 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 1lZCib-0000vS-Rf for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Apr 2021 15:16:37 +0200 Original-Received: from localhost ([::1]:34236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZCia-0003GB-Uw for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Apr 2021 09:16:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60572) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZCgs-0002Im-Mq for emacs-devel@gnu.org; Wed, 21 Apr 2021 09:14:50 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:49467 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZCgo-0003qi-8h for emacs-devel@gnu.org; Wed, 21 Apr 2021 09:14:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:To:Subject:From:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RirykXMCrMRlgs/MfphRMdTxhnVi877LViQJxq2id4w=; b=AgukGDnB+UudKe5WTE/ryTuKy5 plAALhWgvTuZLL1wWOuOm6UatCpRXTlUqslPiV3/f9ZTSnnEebbHoOdQgtkXEqgBWdCw1Fcwd7RKJ vLFSLNlDyYe/0Zo+l6bMJmFL6J1fDH5gOIbVJzmt9+CQCzTTHfGDqGaq74bWHCxTI17Y=; In-Reply-To: <87h7k0c7tz.fsf@posteo.net> Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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:268231 Archived-At: 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. As with `completing-read` it should be possible to decouple the components in ui, filtering language and backend/object representation. > 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? Daniel