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:16:22 +0200 Message-ID: <09f2a253-84ba-5cfd-552e-0b89109864a5@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> 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="24722"; 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:17:12 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 1lmaUK-0006Eb-IU for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 13:17:12 +0200 Original-Received: from localhost ([::1]:40728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmaUJ-000633-8O for ged-emacs-devel@m.gmane-mx.org; Fri, 28 May 2021 07:17:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53174) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmaTh-0005Mh-P8 for emacs-devel@gnu.org; Fri, 28 May 2021 07:16:34 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:48087 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 1lmaTe-00078e-D6 for emacs-devel@gnu.org; Fri, 28 May 2021 07:16:33 -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=5hoxOQIOht7VxHHvzmCY7qDJMTvdIXLohH3nmNEK5oo=; b=KxutQahUvpmp5T2P+DtmSZXi+U qJOjF30Pf9KXX7Lp+zfvNRAXBrqd6X4Q6Oqt/be6MAaWtdio9/rwdiDbvxN92cs0TExpj04nk2wlk 5tZtR6xdCaRsaIyxgDvEOuoIP9mFnvmrjwnus10zlPytWE9Gi6jyYlxPS3RgOGBToxd0=; In-Reply-To: <878s3zuq47.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:269989 Archived-At: On 5/28/21 12:09 PM, João Távora wrote: > Really? The names of the function mention Company, because at the time > company frontend was their only consumer of them, but the point here is > to make other frontends consume them. Anyway, as I understood it they > were only examples. Well, the point here is that these are not annotations, which are not meant to be displayed. So what are we talking here about. >> The name `resolution-function` does not suggest that the function is >> supposed to return annotations or decorations. > > Ok, change the name. Name it `decoration-function` or `annotation-function`. Then I am more happy with the proposal. >> It can return anything - this is the over-generalization I am talking >> about. > > I like that it can return arbitrary pieces of information attached to a > single completion. That is a generalization, I don't understand the > "over" problem. > >> This is not an extensible design. I would like that the frontend has the >> ability to show arbitrary fields, not only fields it already knows of. > > That's generally impossible. How can a frontend know how to display the > field 'magical-animated-gif-boomerang-video-url' I'm thinking of > attaching to the completions of my completion backend? Eventually, very > fancy frontends will be able to do that, and it's my job to convince > them that this is a super-important piece of information to show the > user, but some frontends can't or won't show video for example. It is not impossible as long as we require the annotations to be strings. The affixation function also returns strings. Alternatively we can specify that the function may return other types which are then up to the interpretation of the UI. There should be a possibility for the UI to request all annotations and then it can display the fields it supports. 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. > To restate, now that I have Icomplete mostly fixed for verticality and > nice scrolling behaviour and also reworked for easy annotation support, > I think Juri's idea is a fine one (with the cardinality adjustment -- > one field per call). >From my side the changes in your icomplete-vertical-mode-improvements branch are fine. Daniel