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: Simplification of `affixation-function` Date: Tue, 27 Apr 2021 19:39:34 +0200 Message-ID: <2fa797e1-6a34-abac-2820-440e5edbc494@daniel-mendler.de> References: <87y2d777r2.fsf@mail.linkov.net> <35e2e508-cd0a-b921-af96-9c12da92faf3@yandex.ru> <126afe1f-8ac5-69fc-f6af-a586bc354d03@daniel-mendler.de> <1e9bb418-9f1a-68ee-14de-e68f30f88b0a@daniel-mendler.de> <50cfaa6f-67c0-117f-41b5-10fefabee0d2@yandex.ru> <8735vbr7w3.fsf@mail.linkov.net> 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="28865"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Juri Linkov , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 27 19:48:25 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 1lbRou-0007Re-Uy for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 19:48:24 +0200 Original-Received: from localhost ([::1]:48000 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbRot-0001uP-To for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 13:48:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44300) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbRgZ-00063s-3Z for emacs-devel@gnu.org; Tue, 27 Apr 2021 13:39:48 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:54741 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 1lbRgT-0005YY-7M for emacs-devel@gnu.org; Tue, 27 Apr 2021 13:39:46 -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=6tfOiYRCc4r+qEc7eB6u6hUhargxxwwx4vLKEpwjZ3Y=; b=fOOnuWzM/6Ka9bXr0Njr51kSPH WiAwo0KQKefL7rOQAlrh2UXonM642XZv0GoXRM5mxbluAiGk1G0od6i4SJFaeWIVzEYsI7f1vutIR HbAg+fR+vITrECcpVlpobk1mcDlgpGPFfaiKEkWInN+XdpOn2/E7kofVm0OHapJv4bk4=; In-Reply-To: <8735vbr7w3.fsf@mail.linkov.net> 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:268541 Archived-At: On 4/27/21 6:48 PM, Juri Linkov wrote: >> You can also note that the third (suffix) element is always an empty string >> in both of these use cases. So affixation-function was really added to be >> able to add a prefix. > > affixation-function was an improvement over annotation-function, > but nonetheless it has limitations too. What would be a better thing is > like Daniel proposed a new meta `group-function`, I'd imagine a similar > meta `format-function` that could receive a candidate and return > a string to insert to the completions buffer. > > Then the caller e.g. help--symbol-completion-table could define whether > to append "u", "a" and "c" in parens by using on a candidate something like > (format "%s (%s)" cand (cond ((fboundp (intern cand)) "f")) ...), > or prepend a dimmed letter as a prefix, or to use an icon. > > The same `format-function` could be used to remove the group prefix > when `group-function` is in use, instead of providing an additional > argument `transform` for `group-function`. There has been some confusion regarding this already. Some people (me included) had assumed at some point that the affixation function is allowed to transform the candidate, since the candidate is part of the returned list elements (Now I know that this is not the case, but the function should be allowed to add faces). It should be possible to relax the affixation function to allow a candidate transformation, then we avoid the addition of another format-function function. One may ask - why not change the affixation function then such that it only returns a single string? We could do that but I think it is valuable to separate prefix/candidate/suffix for display in a tablist. The group function candidate transformation is also to be distinguished from a potential transformation performed by a format/affixation-function, since the group transformation should be only applied when grouping is active. It is therefore better to keep the transformations separate. Daniel