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] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Sun, 23 May 2021 23:31:54 +0200 Message-ID: <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> References: <87zgwlb4xc.fsf@gmail.com> <617d06ca-27bf-2ae8-26eb-1042123499d3@daniel-mendler.de> <87pmxhb1rs.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31772"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , monnier@iro.umontreal.ca, "emacs-devel@gnu.org" To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 23 23:33:18 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 1lkvin-00083B-On for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 23:33:17 +0200 Original-Received: from localhost ([::1]:45224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkvim-0001FM-Pz for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 17:33:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60236) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkvhr-0000Ss-Db for emacs-devel@gnu.org; Sun, 23 May 2021 17:32:19 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:45287 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 1lkvho-0007iz-Tb for emacs-devel@gnu.org; Sun, 23 May 2021 17:32:19 -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=uF0na/lcCX9XxaoXULU0ODcIY3tOyLyOvvTz7FnkoUs=; b=yikuZs6wDQCeRU8dRL0ZVmw9Ix RVz/Rk2UM3o8Zqr3Y35Wa3azEDXLt028ZUJmQ9RKbJXd7wFw6OrSdWmvCsqAvxpy5ZR5NsjUsg+F9 +g28wbvseL7eJUMLwH6Kt0Eq3KdoV8/F0F8hJMilIbo2FaqnVDW1JUm7b3ZCOb3Xtlr8=; In-Reply-To: <87pmxhb1rs.fsf@gmail.com> 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:269705 Archived-At: On 5/23/21 11:04 PM, João Távora wrote: >> I would also be happy with an extension to the `annotation-function`, >> where the returned annotation string is the suffix and can be >> propertized with an additional string for the prefix. > > Either that, or it could return a list instead of a string, and then the > list would be interpreted as "affixation function" results. A list return value is not a good idea since that does not allow to write forward and backward compatible code. This is actually an advantage of the `affixation-function`. It is a non-intrusive addition. The same holds for the recently added `group-function`, which I proposed. >>> I also don't understand why :affixation-function is given a full list of >>> completions, when it is presumably meant to return a list of exactly the >>> same length. Seems like a potential hazard to allow this function to do >>> filtering. >> >> It is not allowed by the definition of the function. > > Yes, but users love to foot-shoot and who is going to enforce that? > Your icomplete patch doesn't, for example. Whereas if it were a unary > function of a completion string, the hazard wouldn't exist. Of course. > and it seems one purported advantage of having `affixation-function` see > all the candidates is to be able to do layout decisions since it knows > the longest and shortest candidate. Indeed, that was the point. Unfortunately it turns out that having layout decisions based on all the currently visible candidates will give bad results when scrolling. So I am never using that capability in my packages. You may have seen the Marginalia package by Omar Antolín Camarena and myself, where we add rich annotations to many commands using the `annotation/affixation-function` (https://github.com/minad/marginalia). We are doing manual alignment there. So from my current experience the advantage is small. > But I don't understand why these decision should be done in the data > backend. The backedn should only annotate a completion with a possible > _hint_ on how to layout ("prefix" and "suffix" are hints). It's the > frontend, who is who knows what to display and where, who should be > responsible for the layout. Yes, alignment should better happen on the display level. >>> So, unless I am missing something (known to happen), this seems like a >>> misdesign which would be nice to correct before the Emacs 28 release >>> and/or too many external packages start relying on this. >> >> For what is worth, my packages already rely on this. But I would have >> this changed quickly given a modified definition of the >> `annotation-function`. I am not aware of other packages already using >> this functionality (I searched around for this at some point). > > That's valuable information. Let's wait for Juri and Stefan on this. If it is decided to change this, I think it would be best to use text properties for this. The `annotation-function` should continue to return suffix strings and additionally, each suffix has an `annotation-prefix` text property attached. That would be a more minimal API change than the addition of the `affixation-function`, while still being fully compatible. Daniel