From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Fri, 28 May 2021 16:57:45 +0300 Message-ID: <74e97523-2f86-f365-d183-fddc015fc0dc@yandex.ru> 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> <6937cf53-98fc-98ff-3026-b5eccf461a76@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21494"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Juri Linkov To: Daniel Mendler , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 28 15:58:31 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 1lmd0Q-0005SM-Rw for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 15:58:30 +0200 Original-Received: from localhost ([::1]:43310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmd0P-0005e2-1O for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 09:58:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmczp-0004pp-4V for emacs-devel@gnu.org; Fri, 28 May 2021 09:57:53 -0400 Original-Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:37468) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmczl-0002WG-Up for emacs-devel@gnu.org; Fri, 28 May 2021 09:57:52 -0400 Original-Received: by mail-wm1-x332.google.com with SMTP id f20-20020a05600c4e94b0290181f6edda88so4637804wmq.2 for ; Fri, 28 May 2021 06:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MlJkpAjytXqkon7TZ0VsM2PiqxNdK4S3dJ5mgqCiyfQ=; b=F/KYHBOgR4XrPDzsxnGTNhjAMLAsvWvn7RXr4OogCmoisPGMLaXOpGY+nIy7IaiwPN 7Um3GPY8l0r/12Xk683b6QNmOHjiDNfL84NNi4lMTEfwTTcoN2uGkuEPsoODhQba354N 3u1J6Ewt2ynyGV4vigf0vr/V5qm+CTV9pse1rR4o6qu04IHTXFEwSi2rWhXLdOTQYLuI uZHD6ZUxYAHv83K2gRq5fwG7gm8vSJo1ubvJpf2/xbM1uNyVFGoFdhC8qoO4txJbSKdr Tk3rYul4gZhvZt15DGuUz0uV5IUfNAFV7CmgfRca0f0ZBIVYEi44xQNr4oUocLbxcXYZ xG9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MlJkpAjytXqkon7TZ0VsM2PiqxNdK4S3dJ5mgqCiyfQ=; b=qCnO/r1B2WvkOBvudSxjlEtnW6oxsgY6hIREC8iDyfew4tIhVmzqR2mop1/g/JiwJn Y4j5SOLqobj8Sd/chJH0pLUxVPdhc5cP824y+tiJTBKWZzD32jroHwHylqtzOo9+BMEn MQlkl8CKM1l5eOuQ/GbRqZNiBafeb0XhlX5JZGO1yr9RMmHrzTRJkwC84vX+9pVngA+2 17G0XXrfXlvOgE88XnF0qmt+1vo5qryW6kHwp8zQ79FnzYevyhqiyZYa0Ra2368PGDrm PFCy4LfSBHGB6FlTfCVDr+9/EavdtxmQEZrtoFMaHgCrl3MYR09WCC/NUgPs8A3K/99i 2UQw== X-Gm-Message-State: AOAM532j/O4TpIR71HdAo9XpdyF8wRvxghK3pjqtANRokrCTH4ZkOSQK sTEDt1wCiG1D+g5csCuw3Mg3yBwVXew= X-Google-Smtp-Source: ABdhPJydgRgNyz0xqp+w0cMC71Gysyds/fagwrpxVFgj0L9zBS+2Lf0ZhOI0B14BD4cLO+SOenUjvg== X-Received: by 2002:a7b:c10a:: with SMTP id w10mr13856317wmi.21.1622210267964; Fri, 28 May 2021 06:57:47 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v15sm14541808wmj.39.2021.05.28.06.57.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 06:57:46 -0700 (PDT) In-Reply-To: <6937cf53-98fc-98ff-3026-b5eccf461a76@daniel-mendler.de> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::332; envelope-from=raaahh@gmail.com; helo=mail-wm1-x332.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:270003 Archived-At: 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. > 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. Aware: yes. Seen the screenshots, haven't tried it myself so far. > 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. > 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. 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. >> 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. Well, it definitely shouldn't choose the presentation of "kind" annotations on its own, like in your earlier example. > 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. Worst case, Marginalia could define its own completion-info-columns-function. But yes, it would add an extra bit of rigidity to the system.