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: Fri, 28 May 2021 11:09:12 +0100 Message-ID: <878s3zuq47.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> <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> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@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="23399"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Juri Linkov , Dmitry Gutov , 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 Fri May 28 12:10:55 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 1lmZSA-0005yr-EB for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 12:10:54 +0200 Original-Received: from localhost ([::1]:55636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmZS9-0008Jj-EO for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 06:10:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmZQd-0006fn-Da for emacs-devel@gnu.org; Fri, 28 May 2021 06:09:19 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:53936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmZQb-0004jK-70 for emacs-devel@gnu.org; Fri, 28 May 2021 06:09:19 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id h3so1802269wmq.3 for ; Fri, 28 May 2021 03:09:15 -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=VcpUUmdYl4gv7qKMFuDuRL+4IHSOsMTrhHHkj1UZ7qU=; b=EWri5crWftde1EGxcvjsgEl3OLyA8Fg+eWA5q/ty0CP0QDxBT2lYECvkObq1p2ZXuE mvS4c/aKYB/zvLZ67okn6nITpUBi8wOz2OccsR6KQVWL+6LXjM6ZEoQGlWBTN0fd5aZQ nxTetbC/Ud7pJZFrlRSzMdKL5Jr52Uy0SQB5h2eudTRxyiscJsqfnrao+8EvxBX1RP1g hs0qIlXtbttYdvrfi/hqpFvrVPjPKnGgnXF2px5RjBFR5mePWwXSnQ05OfB2WiEkAbpK C4y/vLonkk66lNrjdt1BWm74Dr2EwvhagvYBTuxTCEDqnRc5LMqenWi5zLJVQ+NGlAWQ 1SFQ== 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=VcpUUmdYl4gv7qKMFuDuRL+4IHSOsMTrhHHkj1UZ7qU=; b=eBWNadlVGCzHN9iYksUJ+5UTqkCE00lZflyxEl9O+7whoX9L0rz+HOGI+1WU04CTGs tPw8P8hCIcjPg7wZ3f/N2EbwYnngyeWXsn3amnpkgGbKPdRuiIcR7ArS3iLwwwyHVycf f0kqoeXJKlLDJqdLenzCC8KFRySswNSQAAvrguZf3083YWps4eUfJy4HdHZwLIvdYTBh +5A/C3iRxgw2Z6KsOwNMbg1LE2ev0KmNtBrmhpcKmor/wq++vwLW/WBzq1JWw6t4lfWh jboxY4Ew54JfVW0DJAz5xCyVnRfGHaL+jIswAcWSTUxk58iMXJKywQPOgnOMQoZEZwUe oKWg== X-Gm-Message-State: AOAM532hd+uYzYT0BAJbx6i+vaJpYG+0wjMHJ/AT3SqxhA+yFv3j5Jkw 8KHhJVY7FVU3vi4ihm9wNNs= X-Google-Smtp-Source: ABdhPJxrq8O+omDrSJTgmut+ZuaJt0F9CTuM9EzwPQHFMm87gBFPL9lr8+/OrRpiDOxT8Jw1fREFlg== X-Received: by 2002:a05:600c:414c:: with SMTP id h12mr7705909wmm.53.1622196554554; Fri, 28 May 2021 03:09:14 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id y2sm6645630wrl.92.2021.05.28.03.09.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 03:09:13 -0700 (PDT) In-Reply-To: <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> (Daniel Mendler's message of "Fri, 28 May 2021 11:06:14 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x32c.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:269988 Archived-At: Daniel Mendler writes: > On 5/28/21 10:34 AM, Jo=C3=A3o T=C3=A1vora 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=C3=A3o. 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. >>=20 >> 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. Really? The names of the function mention Company, because at the time company frontend was their only consumer of them, but the point here is to make other frontends consume them. Anyway, as I understood it they were only examples. > > The name `resolution-function` does not suggest that the function is > supposed to return annotations or decorations. Ok, change the name. Name it `decoration-function` or `annotation-function= `. > It can return anything - this is the over-generalization I am talking > about. I like that it can return arbitrary pieces of information attached to a single completion. That is a generalization, I don't understand the "over" problem. >> Again, I can't understand this. In the frontend: >>=20 >> (let ((res-fun >> (or (completion-metadata-get md resolution-function) >> (plist-get completion-extra-properties :resolution-func= tion)))) >> (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. That's generally impossible. How can a frontend know how to display the field 'magical-animated-gif-boomerang-video-url' I'm thinking of attaching to the completions of my completion backend? Eventually, very fancy frontends will be able to do that, and it's my job to convince them that this is a super-important piece of information to show the user, but some frontends can't or won't show video for example. To restate, now that I have Icomplete mostly fixed for verticality and nice scrolling behaviour and also reworked for easy annotation support, I think Juri's idea is a fine one (with the cardinality adjustment -- one field per call). Jo=C3=A3o