From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Simplification of `affixation-function` Date: Mon, 26 Apr 2021 01:31:53 +0300 Message-ID: <50cfaa6f-67c0-117f-41b5-10fefabee0d2@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19025"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 Cc: emacs-devel@gnu.org To: Daniel Mendler , Stefan Monnier , Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 26 00:32:40 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 1lanIt-0004oy-P8 for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 00:32:39 +0200 Original-Received: from localhost ([::1]:55470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lanIs-000712-P6 for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 18:32:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lanIF-0006aW-6Z for emacs-devel@gnu.org; Sun, 25 Apr 2021 18:32:00 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:38550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lanID-00008B-1Y for emacs-devel@gnu.org; Sun, 25 Apr 2021 18:31:58 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id p6-20020a05600c3586b029014131bbe5c7so869905wmq.3 for ; Sun, 25 Apr 2021 15:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N5WLYawvc9vLmBtv3A9VIwE+rhx5FhHDdxTvl8vFNR0=; b=H8zMiR3D7m2lGfVgAtFIc+IEMChxkV2maa5a5X3VQVF4eWdq72ZIM1QDjXShH1AhcG LuiOhS2hpWAzniIUjtuPxnuvwxVj87pFycXNO3h3ZLQfFr6TwAybsnTEQmF7oCxVoIvh Xi3yfQyCDjbBUk6/BLG7EHWygzqQ0s+hpL9iMxcmksS/s5qWLKlVqfAN5Gq2oAjRLxx+ aHF7XiGF4H2vcX9CHpaYnyupj3+aFAbSloBzz6SUSe/T7yZmZ88l641uOj6s4MWf108m BhoZqs8kkdkLLblZFqvKdWTIFIUTbgmXD5Yw0mUj/0N91tQDJWIRiGCUgPsuUDpwSfRL NUjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N5WLYawvc9vLmBtv3A9VIwE+rhx5FhHDdxTvl8vFNR0=; b=IwXJNeMhNCS4fXM7QyYd9uN8Jwsk6UjAYDbeXDzpSxVdKfbczD8N0qmIOZDAtgBnWg 2vOpZonyHDPQruBQvpu8I83ALr1cW1xlBmeg2ZqfpaEHiJFgHkapAdwRFvxxvM046ZVk kD7ULio/vEIlRgCx7Hg99wCqth+VLjR54KXPKDWB8FHfdC7JxD3Yzsm9CDNaOppIX3aO pBvwRDxvYVb3DBs0pZ9vXjU6JAGssvAoWYg2bihM3jRPIH1dY1s8YLs40y2KnG3pID7E PW0O8fCkut6DIV7nip3jpeGV5hulrNKDMKDfLwVV+n6H7uoivJsL/oP5bSY8rsmaT3ox 823A== X-Gm-Message-State: AOAM530Wo72FH+pCX9Bmz9xCDSJHrt8SATzta+1EXvKo7aArzxUthU8g Cctj1z3+ECJ54ZslmJflz1tM9GLDWzY= X-Google-Smtp-Source: ABdhPJylN07xDLzAltl6fWR+swycr8bYfHU1Mx/+Q+9l7zwRWO5OUghpTLZ086NZwsbUD6O3LGPyEw== X-Received: by 2002:a05:600c:3587:: with SMTP id p7mr4735160wmq.75.1619389915627; Sun, 25 Apr 2021 15:31:55 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s64sm15482012wmf.2.2021.04.25.15.31.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Apr 2021 15:31:55 -0700 (PDT) In-Reply-To: <1e9bb418-9f1a-68ee-14de-e68f30f88b0a@daniel-mendler.de> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=raaahh@gmail.com; helo=mail-wm1-x334.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:268432 Archived-At: On 25.04.2021 21:08, Daniel Mendler wrote: > On 4/25/21 7:58 PM, Dmitry Gutov wrote: >> I guess my problem with it is, with the apparent end goal of >> flexibility, it ends up targeting only the default completion UI, and >> the more an alternative UI is different from it, the worse the result >> can look. >> >> And without semantic information, it fails to take advantage of the >> additional features the alternative UIs might provide. > > You are right about that. As things stand now the > annotation/affixation-function only work well for the default > completions buffer and the vertical completion UIs. Isn't Company a vertical completion UI? > The > completion-at-point popups are very different from that, so it is only > fair if they try to invent their own metadata functions as you are doing > in Company with `company-kind` etc. It's fair that they try to invent new stuff, but it's more economical to reuse the stuff when feasible. > However I am a bit critical with regards to the "semantic information". > As far as I understood you use some icon names for that, but this > restricts the purpose of the annotations. Maybe it would be sufficient > to use a more crude solution, where you only specify that the > annotations/affixations must be sufficiently short in order to display > well in the popups, without going the full way to the semantic kinds. There are currently only two places where affixation-function is used in the core. One of them is the aforementioned help--symbol-completion-table. Regardless of whether there will ever be a completing-read-function based on Company (it's not hard to do, actually; mostly the popup rendering method is holding it back, but I had it working with company-posframe), if help--symbol-completion-table-affixation plugged into :company-kind instead, the users could see the icons already familiar from completion code, from other backends, they wouldn't need to puzzle out what the "u", "a" and "c" characters mean. And other completion frameworks can pick up this feature too (maybe even reuse the icon mappings, we'll see). The user can also customize the icons' look, choose whether they should be SVG, text, icon font characters, or so on. The other use is in read-char-by-name. And I can admit, seeing the characters in the first column is slightly better than following each completion. Not by much, they still work well enough as annotations, but seeing them in the first column is a bit tidier. What would I do? First of all, keep them in annotations, because just one slightly better-looking use case does not justify the added complexity. If someone really wanted to improve positioning of annotations for that completion table, there are other options: - Add a custom var that aligns all annotations to the right, then they'll also be in one column. Company has such an option already. - Create a var specific for the default UI that would move the annotations to the left of the completions. read-char-by-name could bind it to t before calling completing-read. Then the *Completions* rendering code would do whatever is necessary to render it correctly at the requested side. But since mule--ucs-names-affixation, aside from information, also contains presentation (spacing and alignment chars), it would be infeasible for a completion function that doesn't want extra stuff on the left to render its result on the right. 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.