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: Sat, 24 Apr 2021 23:17:56 +0200 Message-ID: <9ca07e0f-48f9-ba21-068c-694453fc79d8@daniel-mendler.de> References: <87y2d777r2.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13723"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 24 23:18:38 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 1laPfh-0003RH-TT for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Apr 2021 23:18:37 +0200 Original-Received: from localhost ([::1]:50402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1laPfh-0006n1-0f for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Apr 2021 17:18:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1laPfA-0006He-3W for emacs-devel@gnu.org; Sat, 24 Apr 2021 17:18:04 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:55745 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 1laPf7-0003iM-QL for emacs-devel@gnu.org; Sat, 24 Apr 2021 17:18:03 -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=+foWzCNcbAnS1d1e8StAFivTi68DaLEfle8S4rQa4n8=; b=RwRuHLSWQLrkh0IIBQeFEYAXLb JbP34GTs3nRotvJGMn9tSTvrjmOTRMZCqW9MjyYLbpqtd6SHhP+4ci+n6vNoQF3AoeFyZycIhIb+2 e2pTKnHbhdDuEZ0j8oEo+cbVVLdJRiT4GOZ8GlNnSZp5tgYpCnQ19Ao4wu4ueAWl/ZH0=; In-Reply-To: <87y2d777r2.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:268346 Archived-At: On 4/24/21 10:22 PM, Juri Linkov wrote: > If the logic of specifying the elements is too confusing, > then such simplification is welcome. > Please note that only the documentation could be changed > to remove mentions of the ability to specify only suffix > for `affixation-function`. But code will remain unchanged > because internally it depends on the predefined order of elements: > “completion + suffix” or “completion + prefix + suffix”. > There is no backward-compatible way to change this order. I think it is slightly confusing and unnecessarily complicated. But if you want to retain backward compatibility, there is no way back. However since the `affixation-function` has only been introduced recently, there should still be a time window to change the definition? There is no released version of Emacs with `affixation-function` support. (If it is decided to change the definition it should be feasible to go over all ELPA/MELPA and apply patches to all packages which already make use of the `affixation-function`.) > More than three elements are already supported since e.g. the > total length is calculated as a sum of lengths of all strings: > > (apply #'+ (mapcar #'string-width str)) I see. So all the later elements are suffixes and concatenated? This seems like an unnecessary completion given that the completion-table implementor can already concatenate all the suffixes. Or is the idea that the UI can show all these suffixes in some kind of table-like view? It seems that there is at least need for better documentation. My proposal is to only allow three-element lists and remove support to specify only the suffix. And one could keep the door open by allowing more than three element lists for additional annotations. Let's say you want to specify some additional help/tool-tip text for example. Daniel