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, 7 Apr 2021 18:57:02 +0200 Message-ID: References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <3ec7e2e58a100426a22e@heytings.org> <877dleb2px.fsf@posteo.net> <87blaq5amw.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="27237"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org, philipk@posteo.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 07 18:57:51 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 1lUBV0-0006xZ-Jn for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 18:57:50 +0200 Original-Received: from localhost ([::1]:33222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUBUz-0007d1-MF for ged-emacs-devel@m.gmane-mx.org; Wed, 07 Apr 2021 12:57:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33364) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUBUL-0006vl-3b for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:57:09 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:38817 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 1lUBUI-0007p1-II for emacs-devel@gnu.org; Wed, 07 Apr 2021 12:57:08 -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:From:References:To:Subject: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=WuGA+yxfpSRioctZ67UZFPM2InE7HYJk54xz+SI+r4o=; b=CIRRuzCYcZDzh7h7KEf77JNEoj ZogqVbYB96qS2nmL6cTSJi3q+L3Px0w97j0ALQekGQcaVZ1sCV+BosqksKTuJRIbyv2chenqVtXU/ nqae3G5XANFXvaz6K9aisLeYwo5LfM4Mgn9aBDB2VXWCqDuOITsnf3x4m3CoILpKknL8=; In-Reply-To: <87blaq5amw.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:267541 Archived-At: On 4/7/21 6:20 PM, Philip Kaludercic wrote: > 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. This is a bit vague. If we have a tree structure one can have some tree-like visualization (like the sidebar tree browsers) or have an outline like in org-mode. But how would you actually navigate quickly? Using Avy-like keys? What if the structure does not fit on the screen easily, what if there are cycles, ...? In the case of `completing-read` the current solutions are all pretty simple. If we ignore the special cases of dynamic completion tables, you just hand it this big flat list and filter until the data set becomes manageable. While some use cases seem to be a bit pressed into that framework (like if you have a hammer...), I think it works surprisingly well in many scenarios with a large number of unstructured candidates. To me it seems much harder to imagine something general which caters for all selection needs using an outline-like visualization. > 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. > I think there is more value in keeping completing-read simple, and focus > it on actual text expansion. Agree. Regarding "interpreting completion as selection" and "text expansion", I am unsure if there is a big difference. You always start with a set of possible completions and only for very few styles a prefix completion is possible. This has been mentioned before in this thread, I think. > 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. I am actually quite satisfied with the status quo given the many package options, where everyone seems to find a good fit. But maybe the name `completing-read` does not reflect anymore what it is since it is often used for something else than simple prefix expansion. The prefix/basic completion is baked pretty deeply in the completion APIs, e.g., `all-completions` and this got relaxed afterwards. Daniel