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 14:32:32 +0200 Message-ID: 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> <87v973t5q3.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="40180"; 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 14:33:29 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 1lmbg8-000AFt-Ad for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 14:33:28 +0200 Original-Received: from localhost ([::1]:47734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmbg7-0008M6-AC for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 08:33:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmbfN-0007NW-MA for emacs-devel@gnu.org; Fri, 28 May 2021 08:32:41 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:44835 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 1lmbfK-0004o0-DC for emacs-devel@gnu.org; Fri, 28 May 2021 08:32:41 -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=goqk8z1p8OSRk7Ul8A292QOwU2/PkEbfIMX3WMhJf34=; b=RQEKg6oY00vOXeo6lsSSoK5hmO 5b3z371Jx5nRJk7wEIcI/sia4fxNqvgj4YG1BFc6oxescQtyuhvhM//vQgHKachrAkSgsQrTfIiy1 fBY6rAt+4sdwHREEwvcWMton2Is+xG5JVx1bQJjdf4QAw6xpRDQdvTWqB7y+2i+X4a+I=; In-Reply-To: <87v973t5q3.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:269995 Archived-At: On 5/28/21 2:15 PM, João Távora wrote: > OK, I think understand and I already addressed this. > > The frontend/backend protocol being discussed doesn't preclude your > intentions, in any way, I think As I said, make a "marginalia" field, > specified to take the value of a list of strings. But then you have to > convince frontends to support it. Icomplete supports 'prefix and > 'suffix right now, make a patch to support 'marginalia. We'll figure > out the relatively priority if a backend wants to return both > 'marginalia and 'prefix. Unfortunately this is not a satisfactory solution. I would like to decouple the components. It is better if the frontend does not have to know everything and all the field names of the backend. I am not speaking against special casing certain named fields in the frontend if the frontend wants to give those fields special support. This is perfectly fine as in the case of the Company fields. I am talking about the common case of arbitrary fields of type string/number/..., which can be supported automatically by a frontend which can show (possibly truncated) strings. So no, you did not address this. You enforce a strong coupling between backend and frontend. >> The "waste of processing" argument by Dmitry is okay - I am not against >> a way to limit the number of returned fields. > > It's more than just "okay": it's pretty fundamental. I don't think it's > a question of limiting the number of returned fields, if the frontend is > unlucky one of those fields may take ages to calculate based on the > processing needed (many backends operate through networks or processes > to request information about completions). It is still a technical detail. But since we agree on this one, there is no need to discuss this further. Of course there can be expensive annotations, where this matters a lot. For example in Marginalia we take some care to not compute particularly expensive annotations. But it is still way too costly to compute all annotations of all candidates at once. Marginalia works best when the frontend requests only a small number of annotations for the small subset of candidates being displayed, as is the case in Vertico or your newly revamped Icomplete-vertical-mode. >> 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? > > Heh, :-) I think it is rather you who have to state the relevance of > that item to this discussion. There are lots of packages out there. > More than "what does it do" we want to know how it is positively or > adversely impacted by the decisions taken here, if at all. Of course, but as soon as I point you to a package specifically you can take a quick look ;) It is just a datapoint in the discussion. Marginalia would not be adversely affected by the `decoration-function`. But there would also be zero positive impact in comparison to the `affixation-function`. From what I've seen, Marginalia could use a `decoration-function` returning a suffix and prefix, which would result in just a slightly different implementation than the current one using the `affixation-function`. If the `decoration-function` would be allowed to return arbitrary fields, then the UI could take care to list all these fields in a tablist. Of course there are other possible UIs. But let's just pick that one. For example in the case of `describe-symbol`, there would be these columns: * keybinding (only supplied for commands) * type (customizable-variable, command, function, variable, face, ...) * description (first line of docstring) * maybe more? So it would be a positive impact if candidates could be annotated with arbitrary fields, which the frontend does not know beforehand. The only thing the frontend must support is the type of the fields. There could be frontends supporting strings, numbers, images, audio, ... >From how I understood Juri in a mail a while ago, he was talking about exactly such a tablist frontend. So I would like to hear his opinion on this question. Daniel