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 13:55:57 +0200 Message-ID: <5f032d77-670e-e83e-fa37-f0a57e08e166@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> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <874kenulu2.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="20935"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Juri Linkov To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 28 13:57:23 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 1lmb7C-0005Db-VV for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 13:57:22 +0200 Original-Received: from localhost ([::1]:54254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmb7B-0000Jm-RL for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 07:57:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmb64-0007rG-7k for emacs-devel@gnu.org; Fri, 28 May 2021 07:56:12 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:45949 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 1lmb5y-0003U0-4V for emacs-devel@gnu.org; Fri, 28 May 2021 07:56:12 -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=HT0MKhmmNx3390XV/gRGWaWD5Kh19SteO7T8Xu11EuI=; b=HgM6jH/f/DIiOQK0nOClM7wTA8 ccR2KODUSbr8HCCW+S+LAy3dDFhxae6x2S7iFDEgXVgiryCcBl0komIhOpYmQpUE/NvUDiszXtVP3 nvelhjT1NrsBZC68ksPkGdDp6TZPveyKndICZC19rXYhn2szOr6hk+PPYGdUGVSxQ0sY=; In-Reply-To: <874kenulu2.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:269991 Archived-At: On 5/28/21 1:41 PM, João Távora wrote: >> 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? I would like the backend to have the ability to define arbitrary fields which are strings and can be printed by the frontend for example in a table. There is a difference between supporting specific fields or specific field types. I would like to have the ability for the frontend to specify arbitrary fields of field type string. Then a frontend can display those in a tablist for example. Juri talked about exactly this use case. He considered adding a formatting function for the default completion UI which uses the tablist. The "waste of processing" argument by Dmitry is okay - I am not against a way to limit the number of returned fields. But there should also be a way to request all available fields, such that a UI can show the ones it supports (but not based on name but based on type!). >> 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. What about taking a look then? Convincing the frontends on a case-by-case basis is not a workable solution. You are the good example here, your answer is "I don't know Marginalia", so how are you supposed to be convinced? All I am asking is a possibility for the backend to return a list of string fields which can then be displayed by frontends which support such a tabular view, or maybe a tooltip. Daniel