From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Sun, 23 May 2021 20:55:59 +0100 Message-ID: <87zgwlb4xc.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34579"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 23 21:57:09 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 1lkuDl-0008oy-BE for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 21:57:09 +0200 Original-Received: from localhost ([::1]:36770 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkuDk-0004ez-AX for ged-emacs-devel@m.gmane-mx.org; Sun, 23 May 2021 15:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkuCm-0003C9-Do for emacs-devel@gnu.org; Sun, 23 May 2021 15:56:10 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:45722) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkuCi-0002mK-8v for emacs-devel@gnu.org; Sun, 23 May 2021 15:56:08 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id x7so6705109wrt.12 for ; Sun, 23 May 2021 12:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=N9IiGAj9PEDkXYPtGqb1qPO2LFGa7ZJMrRf04IRtAS4=; b=NmVpXL4WsfKEfa+g+tnEuJuS9WFhzx6WU08eOwhhb/pb2uAysHlZQiCGXFuzSFJ8is xvyXawUsN7CVbKIBaZnrkLqOFBW90UigB9cqGdZMOuImu423DX94tW1X4byow4NxQ4fe Hvkt1IGDLyP0hC/kB1cf+1i94Zfbk/Y4u0ghkAqHD08+O36Ur8qGbo96PSklBZzXN+RE r0RDA3+HhEz7OOt8j3z4O8kkJt7QCoWMw1JSHD9r6Tqd9JR/rlvoffWSFsKQpVunhhj+ tFFcZWcogEa8AX7A2twUJNFX2FS98TlYqu745i6gTb/jtPvsIoYxF4RAM43sN3sLIHWo wxuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=N9IiGAj9PEDkXYPtGqb1qPO2LFGa7ZJMrRf04IRtAS4=; b=bZYmQhhjtEVBQCKItdDDVDhnkrMnfZJp2FN2vEh9KkDY18QpqciXDpbRZZSLWpHrAd 3+WLNoToxfb8l6fMstT0bkKPDX9iIIeXXLB0gMfoLTvUG66WvRNo83cquc3sdTTc6cbz eKqEbA9F0AvzEzAruGf/ehfS/JLy9rDVxUZdaOdDdCdt1BQG14JeSJfBwc5pVnaCLIu0 jakvdierJ8aBC268PsOH4yTiLRzuAqP8CgI8IsvyDaZNQUuBqumJCJiCGBVSk3ZUYlCK YaXd3b6wtNCnYsh2yoTLRyVttaBjDjdi6KhInCaEWsgkm5SdXrOGFPHm8W39JKMa+bSZ W87Q== X-Gm-Message-State: AOAM533DV5oaeDKjncDoCx5o22o2TD9V4FP4bA/yz2d3mOoxU+pdeQBd hBCBPls4ZgMs8xgm4zYjiI0= X-Google-Smtp-Source: ABdhPJz7gVUtpDSpJ5b3MJFOoSOQagnP+MFBYgjN052CuUVLWWAf2w1cWIHj2VltgWor8bgdS6uU/g== X-Received: by 2002:adf:f58e:: with SMTP id f14mr18994946wro.258.1621799762518; Sun, 23 May 2021 12:56:02 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id f1sm11058340wrr.63.2021.05.23.12.56.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 May 2021 12:56:02 -0700 (PDT) In-Reply-To: (Daniel Mendler's message of "Sun, 23 May 2021 13:10:00 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x436.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:269697 Archived-At: Daniel Mendler writes: > On 5/23/21 11:37 AM, Jo=C3=A3o T=C3=A1vora wrote: >> Can you give a visual example of what it looks like for a given completi= on >> table, ... > > I attached two screenshots: > > - M-x > - `describe-symbol` if `completions-detailed` is set Thanks, I wasn't aware of this new framework and think this looks very nice and is extremely useful. I could get your second example to work, but not the first (the M-x one). What am I missing? >> It seems that neither affixation or annotation were present in non-verti= cal >> icomplete.el before your patch. Do you have an idea why? Should they >> be added there, too? > > There is not enough space in the vertical display. You mean in the horizontal one-line display right? In the vertical display there is space, so we are enabling it there. > The only annotations/affixations which would make sense are single > character annotations, maybe icons. But people who like the compact > Ido/Icomplete horizontal style probably would not want this additional > noise. Furthermore it makes the completions harder to read since you > get prefix-completion-suffix, prefix-completion-suffix, where > everything is mixed up. This is different from the vertical mode, > where annotations and candidates are visually separate and easier to > distinguish. Yes, I agree with this. Thanks for clarifying. After my sig, I attach a very slightly simplified (and untested) version of icomplete-affixate, using `cond` instead of nested `ifs`. But the main thing I wanted to note at this point, is that I find this "affixation" design confusing and flawed. Reading the documentation, I don't see why we couldn't just expand annotation-function's protocol, instead of adding a new (akwardly) named entry point with an priority mechanism. I also don't understand why :affixation-function is given a full list of completions, when it is presumably meant to return a list of exactly the same length. Seems like a potential hazard to allow this function to do filtering. So, unless I am missing something (known to happen), this seems like a misdesign which would be nice to correct before the Emacs 28 release and/or too many external packages start relying on this. There was probably some discussion on this, so this ship may have salied partially. I'm switching this discussion back to emacs-devel@gnu.org and CCing Juri as well. My idea is that it is not too late to: (1) scratch affixation-function (2) make annotation function return potentially richer propertized completion strings. (3) Adjust the handful of users and consumers around this function. Jo=C3=A3o. (defun icomplete--affixate (md prospects) "Affixate PROSPECTS with prefixes and suffixes, given completion metadata= MD." (let ((aff-fun (or (completion-metadata-get md 'affixation-function) (plist-get completion-extra-properties :affixation-fun= ction))) (ann-fun (or (completion-metadata-get md 'annotation-function) (plist-get completion-extra-properties :annotation-fun= ction)))) (cond (aff-fun (funcall aff-fun prospects)) (ann-fun (mapcar (lambda (comp) (let ((suffix (or (funcall ann-fun comp) ""))) (list comp "" ;; The default completion UI adds the ;; `completions-annotations' face if no ;; other faces are present. (if (text-property-not-all 0 (length suffix) 'face ni= l suffix) suffix (propertize suffix 'face 'completions-annotations))= ))) prospects)) (prospects))))