From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Sun, 23 May 2021 22:54:44 +0100 Message-ID: <87a6olazff.fsf@gmail.com> References: <87zgwlb4xc.fsf@gmail.com> <617d06ca-27bf-2ae8-26eb-1042123499d3@daniel-mendler.de> <87pmxhb1rs.fsf@gmail.com> <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16437"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Juri Linkov , monnier@iro.umontreal.ca, "emacs-devel@gnu.org" To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 23 23:55:44 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 1lkw4W-00045t-I1 for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 23:55:44 +0200 Original-Received: from localhost ([::1]:59290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkw4V-0003vJ-K2 for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 17:55:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkw3e-00039Z-2r for emacs-devel@gnu.org; Sun, 23 May 2021 17:54:50 -0400 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:34365) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkw3c-0001y2-2O for emacs-devel@gnu.org; Sun, 23 May 2021 17:54:49 -0400 Original-Received: by mail-wr1-x42d.google.com with SMTP id r12so26505139wrp.1 for ; Sun, 23 May 2021 14:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=SfAsl2Q5W0nthby3Mr9E33HwEZ1sr09PKpHQtd6rdPk=; b=r3xyTBOpChugO/paQrilBv28SdTXro9Mz5YzmXmP7e5OW5AdiUCORIKLubuch2P78x VuxLNQm3MINfKXDckjPCjNUboFrXas4uNQcajzmqKuk4qDf5+J/zIFLVhfCoaCXisawm NF/0Ymq5Qjma+cLKAbF0ungStKTN3fjV/5Tepqf8AvebSSprTj/sC7cWkgxfamx9e9EL snWeppcZ6Qnymo/z9hW/KekZ+/ousFCf7+6ynKR5UrhrNrBqOWKQbd3ai2xhhXKbrB6w zAFSfNRR1Za7eqrf8ZcO4D16v46dn+mkLimDg2JJOX+6hKO2bW9A7RhK71sFyZN7Sn62 C+wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=SfAsl2Q5W0nthby3Mr9E33HwEZ1sr09PKpHQtd6rdPk=; b=gast4K+qav4lo/Q+B0GbaV4EV+w6+O9rg7qARXUw80BZbGa3Kf6AdrS6245MODuxte Dj0HdRNiIBqfn7IYA9Ibl0LJGxe5sIJmKwSOGNA37HyFb0ifn/UxLvJ6A8Mn5dehGide yVBprddB9hHPB/PhMpfWc9kaSiQZftClM6Z+v8GEx0S7vvY3vZrmgMClNym4620B6uyL JuMnE2QQ1qDm7FjdTsWdBj5xj3AjXLXl8Xch/4g++I0XejaOpoDdvtNA69iIuVLlRaie 8dBi/ZsDUX864UtA3gO5P0eMaunZRadGgScAn2jBd9nCtVY8A5CYcORlMXrtF6VAi1Kg x/sA== X-Gm-Message-State: AOAM530OdhjX9+j7HcdsXWHkx763ulDSW1P6adkzw7rt4scs3vYjZBwl 42gxnmDGHUX5MRQcRFeE8l8= X-Google-Smtp-Source: ABdhPJz0CeHUOsGulBmefsN9cKDatM52/LoLlNOFcQDmuIVi4ZSiRrdTE6E9cFrD5ueSe7pxVt91MA== X-Received: by 2002:a5d:5388:: with SMTP id d8mr18459291wrv.423.1621806886571; Sun, 23 May 2021 14:54:46 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id 61sm10612937wrm.52.2021.05.23.14.54.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 May 2021 14:54:46 -0700 (PDT) In-Reply-To: <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> (Daniel Mendler's message of "Sun, 23 May 2021 23:31:54 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42d; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:269708 Archived-At: Daniel Mendler writes: > On 5/23/21 11:04 PM, Jo=C3=A3o T=C3=A1vora 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. >>=20 >> 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. Yes, good point. >> 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.=20 > > 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=C3=ADn 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. Good to know that feedback. >> 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. Exactly, in the case in point, icomplete.el. >>>> 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). >>=20 >> 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. Yes, let's see what Juri and Stefan have to offer here. By the way, as a tangent to this, but spurred by your activity and improvements to icomplete.el, I'm also thinking of enhaving icomplete.el to allow a different type of scrolling in icomplete-vertical-mode where the active completion isn't necessarily shown in the screen line of the minibuffer. So that it acts more like a classic dropdown. Kind of company-mode but in the minibuffer. Another idea is to make icomplete work for `completion-in-region-function`. > Independent of the orthogonal discussion about the pros and cons of > the `affixation-function` is the patch (maybe including your > simplification) acceptable to merge? If a specification change is > later made, Icomplete is quickly adapted. I'd prefer if we wait a bit. For one, adding this to icomplete-vertical-mode would encourage more backend writers to use what we both seem to agree is a flawed API, thus making the effort we are discussing more difficult. So let's give Juri and Stefan some time to opine on this, and then maybe work on a patch that overhauls annotation-function. Jo=C3=A3o