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 15:14:48 +0200 Message-ID: <6937cf53-98fc-98ff-3026-b5eccf461a76@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> <5f032d77-670e-e83e-fa37-f0a57e08e166@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12417"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Juri Linkov To: Dmitry Gutov , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 28 15:16:11 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 1lmcLT-00031c-CQ for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 15:16:11 +0200 Original-Received: from localhost ([::1]:55296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmcLR-0000gj-NZ for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 09:16:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmcKI-0008NJ-Fh for emacs-devel@gnu.org; Fri, 28 May 2021 09:14:58 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:44895 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 1lmcKD-0007vl-RO for emacs-devel@gnu.org; Fri, 28 May 2021 09:14:58 -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=oje2Aqe/vZ5puSo3WAdT2o5c+E74aPZJGiDeXlVJmzU=; b=HevQajlZMq/lQK9v5I6IFQv42X 7p/lm7HPlMJD3ne58FyVx1lrDs5cbyDmQ0GIKy6hceO9sgtw1/6wM0Yc8LQCZ9ocWWyP/F2sBgomf VS5ZNRWRXLSd/i1OcfbpKdZMZtbCqBuvz72AMkwKKhu3LS3ynpMF/mhaJVhObGGIuzZ8=; In-Reply-To: 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:269999 Archived-At: On 5/28/21 2:44 PM, Dmitry Gutov wrote: > On 28.05.2021 14:55, Daniel Mendler wrote: >> 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!). > I get that it could be seen as convenient, but why can't the frontend > just request the fields it supports, one after the other? I am not particularly fixated on the specifics of how the frontend retrieves the fields from the backend. I want something different - I want the frontend to have the ability to request all field of a certain type, for example strings. The frontend cannot request fields by names of which it does not know the name. This is the flaw of the current proposal. Then a tablist frontend could easily display those and allow sorting and filtering by column. You may be aware of Embark, which already provides a tablist frontend, but only with the columns candidate and suffix as of now. It would be great to have more columns there, which are specific to the backend. > IME the overhead for the additional function calls is negligible, as > long as we're rendering only a dozen items or so, and not the full > collection (with thousands of items or more). > > But maybe you want a collection of particular bits of data, > pre-formatted for display in a table, and basically not useful for > anything else. You could call it :info-columns-function, something like > that. Which would allow frontends not even care about which columns are > there, or what they contain, and just print them in the indicated order. > > I'm not a fan of having a backend drive presentation like that, but as > long as nobody argues for elimination of "functional" attributes in > favor of the info presented in info-columns-function (meaning, I could > mostly ignore that addition), I'm not going to fight it. Why do you think backend drivers the presentation then? The backend says I have these fields associated with the particular candidate, please display them as you wish, for example As a spreadsheet/table or as an additional popup in Company. The current proposal is such that the frontend must explicitly request the fields it would like to see, which precludes the use case I described above. > But also consider the possibility of having that logic extracted: > > - Have c-a-p-f elements only include the "functional" attributes. > - Add a middle layer, something like an option > completion-info-columns-function, which takes (COMPLETION > EXTRA-PROPERTIES) and returns a list of columnar instructions in the > format you originally wanted. EXTRA-PROPERTIES is the value of > completion-extra-properties when called by the default UI. This sounds a bit complicated. > A possible drawback is that a completion function cannot unilaterally > add a new column without a corresponding change in > completion-info-columns-function. But that might arguably be a good thing. >From my experience this is not a good thing. The completion table should have the ability to add arbitrary annotation columns depending on the data. There is a use case for this (Marginalia or ivy-rich) and from what I've heard, people like to have such rich annotations. It helps a lot with the self documentation aspect of Emacs. And now if we would have an additional tablist frontend, the UI would be even better, since people could take a look at the annotation fields and sort/filter/hide each column separately like in a usual spreadsheet. Daniel