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: [PATCH] `completing-read`: Add `group-function` support to completion metadata (REVISED PATCH VERSION 2) Date: Sun, 2 May 2021 13:01:37 +0200 Message-ID: References: <0bbdeece-90d5-160c-07ec-2ad8edbf9872@daniel-mendler.de> <87czudm7bv.fsf@mail.linkov.net> <976056e8-3d46-db27-32c2-ddf3ca32d5a7@daniel-mendler.de> <878s5090e9.fsf@mail.linkov.net> <69fd42ed-a1a0-adcb-ac8b-caad80cb0967@daniel-mendler.de> <24f3b5e7-3e5e-d00f-3fc4-9d093ca1dc10@daniel-mendler.de> <87fsz7wvu5.fsf@mail.linkov.net> <46a170c1-7d81-8ed5-e61a-d8193b640d16@daniel-mendler.de> <877dkirzvn.fsf@mail.linkov.net> <83a6pd8vg8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35193"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, dgutov@yandex.ru, emacs-devel@gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 02 13:04:59 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 1ld9uE-00092E-Qf for ged-emacs-devel@m.gmane-mx.org; Sun, 02 May 2021 13:04:58 +0200 Original-Received: from localhost ([::1]:48396 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ld9uD-0004oY-T0 for ged-emacs-devel@m.gmane-mx.org; Sun, 02 May 2021 07:04:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ld9r7-0003sB-Uf for emacs-devel@gnu.org; Sun, 02 May 2021 07:01:46 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:57177 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 1ld9r4-0003B7-OT; Sun, 02 May 2021 07:01:45 -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:Cc:To:Subject:Sender:Reply-To: 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=KYZOVMdugkbARkI5rS3gNXGGdD/5KwjV9Zg57lsOLsQ=; b=xMwO0UlBNaGfF/XcTazYcrbIx+ bZE+/DJnGiuRgQnRgEQ/X8ITCBX9PDb6X3PxpDLHTeEFitYH7yXQTJujYNWprJQXDoRZUL8rQ8csI wxJX/zfV6qr/97mpj7Tt/DtlhOKhJmL8jaMku4b1tiTVjEeK7m7mCd7TTiBzINL8fi7Y=; In-Reply-To: <83a6pd8vg8.fsf@gnu.org> 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:268765 Archived-At: On 5/2/21 9:07 AM, Eli Zaretskii wrote: > We don't provide knobs for every behavior, indeed. But where the > "right" behavior is a matter of personal preferences, and there are > large enough groups of people who may want either of the possible > behaviors, offering an option is TRT. Advice is not a valid > replacement for a user option, because writing an advice is orders of > magnitude harder than flipping an option, and requires the user to be > proficient in ELisp. I agree generally regarding advices and options. But here the user already has the option to use the 'horizontal or 'vertical completions format. My argument is that in case the user prefers to read horizontally, the horizontal layout can be used and in case the user prefers to read from top to bottom the vertical layout can be used. 1) horizontal =group1= cand1 cand2 cand3 cand4 cand5 cand6 =group2= cand7 cand8 cand9 cand10 cand11 cand12 2) vertical =group1= =group2 cand1 cand7 cand2 cand8 cand3 cand9 cand4 cand10 cand5 cand11 cand6 cand12 3) vertical with horizontal grouping =group1= cand1 cand4 cand2 cand5 cand3 cand6 =group2= cand7 cand11 cand8 cand12 cand9 cand13 For now didn't see the need to add 3), the vertical format plus horizontal grouping, as proposed by Juri. If most people agree that option 3) should be provided we can either add this as a separate formatting function or as an option. It may be easier to implement this as a fully separate `completion-insert--vertical+horizontal-grouping` function. If 3) is the preference of most people I guess we should even make this the default, in order to avoid to unnecessarily add configuration options which will be used rarely. I think a wait and see strategy may be better until we got more experience where the feature will be put to good use. Juri implemented a patch which adds grouping to the read-char-by-name function. I hope there will be more use cases. In my Consult package I have quite a few use cases for the grouping, but these commands almost always work best with the 'one-column layout due their rich annotation functions. My preference is also influenced by my usage of vertical minibuffer completion UIs (Vertico, Selectrum, Ivy). However in case the annotations are turned off, the vertical and horizontal layouts should also work well with the commands. Daniel