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: Fri, 28 May 2021 11:06:14 +0200 Message-ID: <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> 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> <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <87lf82g10g.fsf@gmail.com> <87y2c24lww.fsf@mail.linkov.net> <871r9t2lsy.fsf@mail.linkov.net> <22880197-6d05-c821-2c58-328ed3cfc02e@daniel-mendler.de> <87eedruui3.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="22987"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , Dmitry Gutov , 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 Fri May 28 11:07:21 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 1lmYSa-0005bA-PO for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 11:07:16 +0200 Original-Received: from localhost ([::1]:33366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmYSY-0005P4-Vs for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 05:07:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmYRi-0004jf-1I for emacs-devel@gnu.org; Fri, 28 May 2021 05:06:22 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:51847 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 1lmYRf-0004li-FS for emacs-devel@gnu.org; Fri, 28 May 2021 05:06:21 -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=pgzQLXn9m3EmBmVY8AOesr+PW0Ovw8uVOnGleLhkCQE=; b=Bl7vm0l4CrbRViDSNoAnGJ8aB0 aZR8dBvtOl+JSTiILtLfmJeQEVcIv2LqdTyau6gO9TAgtyUPhlLWfBWC7jbhhaWZhKPT1pT8uOkKP 1XVx64NA8xOLylBEJfHGlnF2UI2aBKCzfnyOztGa4TSAfVOX5kYMdd/+yQBYjZ92Oc+A=; In-Reply-To: <87eedruui3.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:269983 Archived-At: On 5/28/21 10:34 AM, João Távora wrote: > Daniel Mendler writes: >> >> A better design for the problem of annotations, which we are actually >> discussing here is a `decoration-function` as proposed João. This >> decoration function has the sole purpose of providing additional >> decorations. Unrelated features should be provided by unrelated >> additional functions. The decoration function should return a >> plist/alist of all decoration fields. Then one may want to add a >> `fields` argument to restrict the set fields in case the UI only needs >> the prefix and suffix. A tabular list UI can then present all the fields >> as returned by the decoration function. > > There has to be a misunderstanding here, because naming aside, this is > exactly how I read Juri's proposal of a resolution-function, which I'm > fine to call decoration-function or fancification-function etc. No, there is no misunderstanding here. The example sent by Juri contains 'doc-buffer, 'docsig and 'location, which are all Company extensions and which cannot be considered annotations or decorations. The name `resolution-function` does not suggest that the function is supposed to return annotations or decorations. It can return anything - this is the over-generalization I am talking about. > Again, I can't understand this. In the frontend: > > (let ((res-fun > (or (completion-metadata-get md resolution-function) > (plist-get completion-extra-properties :resolution-function)))) > (let* ((fields-i-know-how-to-handle '(suffix location)) > (str candidate-i-am-about-to-decorate) > (field-values > (mapcar (lambda (f) (funcall res-fun str)) fields-i-know-how-to-handle))) > ...)) This is not an extensible design. I would like that the frontend has the ability to show arbitrary fields, not only fields it already knows of. Then the completion UI can for example display the supplied annotations in a tablist as columns. The backend can decide and extend the list of annotation fields itself. This makes sense since the UI cannot foresee all kinds of semantic annotation fields up front. So to summarize - I consider the current design lacking: 1. It is not extensible. The backend cannot define fields. 2. It is over-generalized, since the function returns not only annotations but also arbitrary data. There is no point in the over-generalized design, since metadata is already extensible with functions or data. Going via the `resolution-function` only introduces a needless complication and indirection. I am proposing the addition of a `decoration-function` which has the single concern of providing annotations/decorations. The simplest design from is something like a generalized `affixation-function`: (funcall decoration-function "candidate") --> (:candidate "formatted-candidate" :prefix "prefix" :suffix "default suffix?" :my-annotation1 "suffix" :my-annotation2 "suffix2" ...) Then the UI can present prefix, formatted candidate and suffix and the additional annotations in a tablist. Maybe it is not necessary to specify a `:suffix` field - the additional annotations could be treated as suffixes in the default UI. I hope we can back to a simpler design here, which solves the problems we are having at the moment - adding annotations or even only prefixes and suffixes. Daniel