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 12:41:41 +0100 Message-ID: <874kenulu2.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> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@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="30483"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Dmitry Gutov , "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Juri Linkov To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 28 13:43:02 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 1lmatJ-0007li-Sm for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 13:43:01 +0200 Original-Received: from localhost ([::1]:48414 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmatI-0003zU-Hf for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 07:43:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57460) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmas9-0003Hp-MW for emacs-devel@gnu.org; Fri, 28 May 2021 07:41:49 -0400 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:53964) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmas6-0001Pc-Tw for emacs-devel@gnu.org; Fri, 28 May 2021 07:41:49 -0400 Original-Received: by mail-wm1-x333.google.com with SMTP id h3so1940176wmq.3 for ; Fri, 28 May 2021 04:41:46 -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=xPyL+LfB0jdFIxNCDwGmRzvOuUQUNx7EDsUILHX3SSM=; b=JnsBHrgX5pKJZEMKSRgKxv0cda0kSJEqfm6lYjTCjVfUU+RbOHOR+3A+L4Db/jBLpM RlfRsTj6b4mquVWTCt/GqcjR+EDw4KupuiXRbZEkH9kh6504jmMDszca7vqbx0GaDcgS 2Z6fyWIty51UpmiHVA43Eq+w0UNPnPxWz+XkVLRZ+5EsNzdVnmn0Qnk4S5tOLlVG6xWD PwnmPV/KjuMesAEWEAnKFx8WfotA9PO+sVyOkxzrshOflN/cC1PiNzogpR2zLvRoR98s JDIVlxxnMIZumKaw4GvUeW6O3RXGTgA95ioYXlE7U1yqZr7PAeX4WvXaPUnZmuYSwlWZ n+zA== 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=xPyL+LfB0jdFIxNCDwGmRzvOuUQUNx7EDsUILHX3SSM=; b=R8SWBcernHEKLhdD8BgktwdqHeQObNivgAzX0ZIzkHLgDXiXU30Jw5KTgGG4j4odb7 OhEyV3K9ICtFe39CHp01Lg4kcwIGhdZ31JgX7r38T1xcm5NM5UTDx7SH92BrW5pooL9r LQz4+473sD2svSyKQh7mbRHLGBDo5WF0elzjS7+jcnQV6sNjSn0tk+eFdK850JmYX3MY r226WkW9ffmZs6hNrhJgW3ASUQ0XbPZ+MdeMFNlyijO2EmNuNh05iKklmrCQrQDh+UZ7 f1A17QM8itDa2U7lE4HSikezTMWmvXuWRhSIoXahmr5CwwjZIp9TcXMsc0vmqPN13cGB zzUA== X-Gm-Message-State: AOAM533KAIlLUmjJpz4CXUq1WdUck9cj9ETAn8duKHmqv+z2U0cqQ4C2 xA9PqYxawFhcO43yZ6a18gaXtEwZnH4= X-Google-Smtp-Source: ABdhPJwPzffaMvyi0aDMxuxerSFkkZgCcx7Bw5zF2cOzwXIElD5aPpIPG2BmFhSpYwviFaUw9MwCIw== X-Received: by 2002:a05:600c:19c8:: with SMTP id u8mr12970604wmq.25.1622202104729; Fri, 28 May 2021 04:41:44 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id j101sm7150566wrj.66.2021.05.28.04.41.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 May 2021 04:41:44 -0700 (PDT) In-Reply-To: <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> (Daniel Mendler's message of "Fri, 28 May 2021 13:16:22 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x333.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:269990 Archived-At: Daniel Mendler writes: > On 5/28/21 12:09 PM, Jo=C3=A3o T=C3=A1vora wrote: >> 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. > > Well, the point here is that these are not annotations, which are not > meant to be displayed. So what are we talking here about. Let's see an example: we are talking about elisp--company-doc-string for 'docsig' or elisp--company-location for 'location', to pick two from Juri's original example. Both can be displayed, for some meaning of display, it's up to the frontend to decide _how_ to display it. In Icomplete: - 'docsig' could be displayed right-aligned for example, depending on available space. - 'location' could be linkeds to a special keybinding and command that would pop a buffer with that location. Other frontends could do other things with it. The Company frontend already has quite specific ways to handle these things, I suppose. >> 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. > > It is not impossible as long as we require the annotations to be > strings. The affixation function also returns strings. Yes, but this does more than merely affix strings before and after other strings. If we insist on "affixation function", we are constraining the layout from within the backend, and a good design principle is not good to mix models and presentation ("MCV" design if you're into ~90's acronyms). But if you're skeptic, don't take this weak argument of authority, observes how it really solves our problem here (and many other problems). > Alternatively we can specify that the function may return other types > which are then up to the interpretation of the UI. > > There should be a possibility for the UI to request all annotations and > then it can display the fields it supports. Why would the UI request annotations for fields it _doesn't_ support? In that case I have to side with Dmitry, who says it's a waste of processing. Why would Icomplete request 'doc-buffer', which is potentially slow and needs a network request in some backend, if it doesn't need to show it, or even know how to show it? > Did you see my submission of the GNU ELPA Marginalia package? The > package annotates the candidates with multiple annotations which are > currently displayed in columns. But this formatting happens inside > Marginalia. It would be great if Marginalia could instead return an > arbitrary list of annotations which are then formatted by the frontend, > for example in a table. The list of annotation fields is not fixed. I don't know Marginalia, sorry. You want a catch-all for arbitrary string annotations that some frontends will do their best to display in a table? If so, in this scheme, make a field called 'lotsa-strings (or some better name, maybe "marginalia" is a good one). Then convince frontends (maybe starting with the ones you control) to give prominence to that field over other ones. Jo=C3=A3o