From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Mon, 24 May 2021 21:38:29 -0400 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> <87a6olazff.fsf@gmail.com> <93d2cfe9-bae8-bf94-486f-7569aa31491d@daniel-mendler.de> <87bl8zivzj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6135"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Mendler , "emacs-devel@gnu.org" , Juri Linkov To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 04:14:33 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 1llMaW-0001Nu-9N for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 04:14:32 +0200 Original-Received: from localhost ([::1]:55968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llMaV-0004tc-8U for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 22:14:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llM1j-0006qr-Pg for emacs-devel@gnu.org; Mon, 24 May 2021 21:38:35 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34426) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llM1g-00044V-Th for emacs-devel@gnu.org; Mon, 24 May 2021 21:38:35 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 09F8780792; Mon, 24 May 2021 21:38:32 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 95AC8803FA; Mon, 24 May 2021 21:38:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1621906710; bh=UnboOdsRg19vqjakM5uhLXi7Vmve7fNF86rbz1fwv1Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=X4QsgGUAPWiMX3mw93HAbUlGtfXvOm1HAGXUiuVRvyvqUEBOSTsPwXHLMiHLJNmwK ju3SzqHsVvap7gM2UB+lPTNbTJHIxLMqMYK4AsGThSrza7OR754TayjwM7u4o9TwfP jJ8lDYYwWoaQh5C2mo7CTKMyLR7qZp8hy2FUArC+vHOlXLcP9otzazonhhsAmREybm 04P7plpZTk7vFtRo4Wt3pod7dJ3T+TJUqHdNc3COZVyEGgcxB3mguiQdoGFooOe8dH bc3wi55WDyJG2Yij/k5qc+n7Z/NIiWQGdug+1FHC/ZoyKlmwxWoEUOqDzNIdRa/QHS hquR348Squc3g== Original-Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 42C8B1204DE; Mon, 24 May 2021 21:38:30 -0400 (EDT) In-Reply-To: <87bl8zivzj.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Mon, 24 May 2021 23:54:08 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:269826 Archived-At: > The ideal API for backends to say what they would like to annotation > completions with: > > - would not allow the annotator backend to affect the cardinality or > order of completions being annotated. > > - would allow the the annotator backend to perform one-time setup and > teardown for the whole set of completions. > > annotation-function provides the first but not the second, > affixation-function provides the second but not the first. > > I think the second may not be that useful for the use cases we have > right now, but let's say I'm wrong and it is. Fine by me. > In that case, I think we're better giving another optional endpoint to > the backend to perform this setup teardown. For example, a function > of a lambda. I don't have a strong opinion on whether the "affixotation" function should take a single completion or a whole list or what. Here are the aspects which I think matter, in this respect: - We're not in the business of preventing people from shooting themselves in the foot, so I think it's fine to pass the whole list of completion and receive a whole list of annotated completions, even if that runs the risk of receiving a list in a different order or with different elements: we can document the expected behavior and just not worry about the sneaky guys. Who knows: those sneaky guys may end up finding an actually good use for it. - For performance reasons it should be OK to call the "affixotation" function one element (or a small number of elements) at a time, so we only do it for those completions which are actually displayed. So this function should not presume that it always receives the complete lists of completions. But here again, this seems to be a small matter of documentation. -- Stefan