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: Mon, 24 May 2021 12:26:52 +0200 Message-ID: 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> <87y2c5nhsr.fsf@mail.linkov.net> 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="13228"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Dmitry Gutov , monnier@iro.umontreal.ca, "emacs-devel@gnu.org" To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 24 12:28:13 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 1ll7oi-00036i-LX for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 12:28:12 +0200 Original-Received: from localhost ([::1]:48990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll7oh-0007lL-8K for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 06:28:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ll7na-000710-RM for emacs-devel@gnu.org; Mon, 24 May 2021 06:27:03 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:57699 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 1ll7nV-0001sM-QM for emacs-devel@gnu.org; Mon, 24 May 2021 06:27:02 -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=7Wd23BkCAZOcCKQh6EhH2cHr9bfoRvYXwf4iYvxloZ4=; b=A0Lerk2UhAPHvp2sD8RVI8wUQq aX2v90Si8vQuYZedF2tI9s6H+OSpAi4x12OHeg5Jx4kyjNvwTaZ5StWUKAWOd93VuC6scy0oZFT2f vrVNWp5tPhI6VlV4vB4qw9QqJFvl8bBGMmviq28Sd93LBNWRqyuECgWlsxPIhPBr6Pmo=; In-Reply-To: <87y2c5nhsr.fsf@mail.linkov.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:269743 Archived-At: On 5/24/21 1:39 AM, Juri Linkov wrote: >> 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. > > This is valuable experience. It looks like you render rich annotations > depending on the available candidates, and reformat the output > when the number of candidates and their sizes are changing, > like the horizontal completions format in the default frontend > tries to fit as many as possible completions on the same line. > > But it seems this works only for limited cases like simple and short > prefix/suffix strings. I can't imagine how such design could handle > multi-columnar rich annotations. Do you mean we cannot handle something like a tabular layout where annotations can be resized on the UI level. Indeed, Marginalia cannot do that since the UIs don't support that. Marginalia is only a best effort thing. If we would want to support such multi-columnar data and present it as a tablist in the frontend the `annotation-function/affixation-function` must be greatly extended. From this POV I also don't see `affixation-function` as a good and all-encompassing solution. The annotation function should be allowed to return a plist of all columns of annotations and at this point I agree with Dmitry, that the columns should get semantic column names. Of course this should be extensible, the data backend should be allowed to define arbitrary such columns. And then the UI can render some of these semantic columns specially (e.g. as Company is doing with company-kind). But I am not in favor of extending the `completing-read` API with these `company-*` extensions. If such a semantic annotation extension is added, it should be non-namespaced ideally since it is not tied to the Company backend. On 5/24/21 1:42 AM, Juri Linkov wrote: >> https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg01320.html > > And later your reply was that annotation-function is the old approach, > and that the default completion frontend still doesn't use > :company-kind. Any plans to add support for :company-kind to > the default frontend? As I argued above, I don't think such support should be added. I hope we can find a better semantic annotation solution which encompasses company-kind, prefixes, suffixes and arbitrary rich columnar data. The question is how this should be done such that in the end the design does not get too complicated. João started this discussion since he was not happy with the design put forward by the `affixation-function`. By adding support for arbitrary backend extensions in the frontend we will go in exactly the opposite direction, ending up with an even more chaotic API. The question if the `affixation-function/annotation-function` should work on a list of candidates or on a single candidate has also been discussed here. This is more of a technical detail, but I also want to stress the point made by Juri in the other mail, that the backend may have to setup some "context" to compute the annotation data lazily. If this setup can only be done once per redisplay of the currently visible candidates, that is beneficial. We are also using that in Marginalia for some buffer switching to the original window, such that annotations are computed there. For example you want to see the values of the original buffer in the annotations of the `describe-variable` command. Of course the backend can also perform some caching to avoid such expenses. In the "modern" incrementally automatically updating UIs like Icomplete, Ivy, Vertico and Selectrum the annotations are only computed on a small subset of candidates, so these costs don't matter so much. For the default UI or other buffer-based UIs, the computation of all candidates and all completions is usually manually triggered or delayed a bit such that only a small subset of all candidates are computed, such that the same argument applies as in the case of the Icomplete-style UIs. Daniel