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 20:40:40 +0200 Message-ID: <7a810694-443a-4942-21a2-11b97ef2c106@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> <2fa797e1-6a34-abac-2820-440e5edbc494@daniel-mendler.de> <87fszb61hs.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="2869"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Stefan Monnier , Dmitry Gutov To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 27 20:43:08 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 1lbSfr-0000R4-My for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 20:43:07 +0200 Original-Received: from localhost ([::1]:59676 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbSfq-0007Ba-Nz for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Apr 2021 14:43:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbSdg-0006XD-P1 for emacs-devel@gnu.org; Tue, 27 Apr 2021 14:40:53 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:44139 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 1lbSdc-0006Kj-Nm for emacs-devel@gnu.org; Tue, 27 Apr 2021 14:40:52 -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=Td3QFLvsOp1szbrfWPH5rXGuc+KPObstVY3glmkxQYc=; b=CeW8cCTvZ+hVlrJcA+CWpt2f3a oebjGO4ZLa0ZevbH23v5SZ34BpaTYhM0JbhYnBV7WOkGIbmRJHHu6e6wqQ9Erx85M+jazdf/JyNB8 ArlGVlPWwfr10VC7+alD8XgfBOWUmwvt0GCu6mQT49xeKlxoeBWCMJv6guRz0r6MXmig=; In-Reply-To: <87fszb61hs.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:268545 Archived-At: On 4/27/21 8:11 PM, Juri Linkov wrote: > affixation-function is called immediately after sorting candidates. > format-function could be called immediately before inserting candidates > only when they are displayed. I don't see why using the affixation function is not possible for the transformation. The affixation function is basically just called right before insertion, right before the candidates are passed to `display-completion-list`. I don't see the need for an additional format function here. >> 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. > > Because completion--insert-strings needs to highlight the untransformed > candidate with mouse-face=highlight. Yes, that's right. `choose-completion` uses the mouse highlight to locate the candidate. But this trick must be relaxed as soon as you bring transformed candidates into the game. In my `group-function` patch I am attaching the untransformed candidate to the property `completion--string`, which is then read by `choose-completion`. Note that the highlighting is still preserved, if no grouping/transformation is used. In that case the highlighting still reflects the untransformed candidate. As such the change is backward compatible as long as grouping/transformation is guarded behind a feature flag. >> 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. > > API would be more clear when transformation is separated from grouping. > So if there is no need to transform group candidates, only group-function > is provided. When group candidates need transformation, then additionally > format/affixation-function can be provided as well. I considered exactly this, but it is problematic. The idea of grouping is that you can optionally turn it on or optionally support it in the UI. The grouping transformation should only be applied when grouping is enabled. This is important since the grouping candidate transformation may remove some redundant part of the candidate which is then displayed in the group title. This means we cannot conflate the grouping candidate transformation with the `affixation/format-function`. We can either go with two functions `group-sort-function+group-transform-function`, where `group-transform-function` is optional or with the boolean `transform` argument I am having now in the patch. I think it is easier to have a single `group-function` instead of splitting this small feature into two functions. Daniel