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 16:10:55 +0200 Message-ID: References: <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> <6937cf53-98fc-98ff-3026-b5eccf461a76@daniel-mendler.de> <74e97523-2f86-f365-d183-fddc015fc0dc@yandex.ru> 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="6112"; 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 16:11:41 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 1lmdDA-0001P7-Gf for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 16:11:40 +0200 Original-Received: from localhost ([::1]:51244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmdD8-0003Vh-SA for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 10:11:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmdCY-0002ih-SD for emacs-devel@gnu.org; Fri, 28 May 2021 10:11:02 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:37343 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 1lmdCW-0002e4-30 for emacs-devel@gnu.org; Fri, 28 May 2021 10:11:02 -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=rtKcnhm/MuYFO/cpwKG66C+I4tngKrX4YCWBaew5bts=; b=cCUUFyp7eVp0z0AlwfkOKUghMR EuTmWJUchCPZWfoyZzOro7Seg/EclDRCbeysBMMLRD++LNorA3LJqILNF/P1lK1ej1uW9d/RKmaDw bppP5kbkb11Ym3KjRbfj1sq8/bL6it0hVZAeqyGnSbDOpi3LLzcoBXUlfNOD0ZO302Tk=; In-Reply-To: <74e97523-2f86-f365-d183-fddc015fc0dc@yandex.ru> 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:270006 Archived-At: On 5/28/21 3:57 PM, Dmitry Gutov wrote: > On 28.05.2021 16:14, Daniel Mendler wrote: > >> 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. > > IOW, I guessed correctly, and you want the backend to make a > presentation-level choice for you: the list of columns to display. Not according to my interpretion. If I have a database with a list of columns, does the database specify the presentation? All I am saying is that the backend should offer a list of available fields to the frontend. What about the possibility for the backend to return some kind of description of the available data? (:kind 'icon :keybinding 'string :description 'string ...) But maybe that's also overkill. >> 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. > > That's "presentation" in my book, especially if the backend also > specifies positioning, which I think has been discussed in this thread > as well. > > Or consider, for example, that you can have a file associated with each > completion (perhaps you're showing a list of definitions or references). > > Someone might like to see the file in one of the columns. Do you show > it? How do you display it? Do you show the basename? Do you try to > "uniquify" those values? These are all presentation-level choices. Okay, I think I understand what you mean. Of course there is already a bit of presentation performed by the backend depending on how it returns the data, in particular if the backend returns generic fields of type string. In order to fix this one would have to distinguish 'string from 'file field types. >>> - 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. > > It's an extra indirection, yes. > > But I think some users might appreciate the ability to customize the set > and ordering of the columns in their completions. > > And backend authors might appreciate not having to make those choices. This is a serious limitation of Marginalia as of now. One could handle this is on the UI level. An intermediate layer is more generic and would work with different UIs. This is probably better, I agree with you about that. >> 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. > > Well, it definitely shouldn't choose the presentation of "kind" > annotations on its own, like in your earlier example. My idea is rather that the completion table returns a field of type, which can then be interpreted depending on its type by the UI. The question is how fine grained these types should be. As you argued string is not generic enough, one would require a special 'kind type and a 'filename type. In the case of the 'kind type the discussion becomes a bit mood since then one has a field 'kind of type 'kind. But this is not the common case, I think one could catch many annotations with some common types. Daniel