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: Tue, 01 Jun 2021 15:30:17 +0100 Message-ID: <87r1hl8xom.fsf@gmail.com> References: <87pmxhb1rs.fsf@gmail.com> <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> <87y2c5nhsr.fsf@mail.linkov.net> <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <87lf82g10g.fsf@gmail.com> <87y2c24lww.fsf@mail.linkov.net> <871r9t2lsy.fsf@mail.linkov.net> <22880197-6d05-c821-2c58-328ed3cfc02e@daniel-mendler.de> <87eedruui3.fsf@gmail.com> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <875yyxaoxp.fsf@gmail.com> <871r9laj6a.fsf@gmail.com> <1b73a130-204c-76fb-2b60-02b814aee0f0@daniel-mendler.de> 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="25349"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Juri Linkov , "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Dmitry Gutov To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 01 16:31:43 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 1lo5Qk-0006Pi-MB for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 16:31:42 +0200 Original-Received: from localhost ([::1]:57842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo5Qj-00020K-Nk for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 10:31:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo5PU-0000Ui-FX for emacs-devel@gnu.org; Tue, 01 Jun 2021 10:30:24 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:39779) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lo5PS-0007W7-E1 for emacs-devel@gnu.org; Tue, 01 Jun 2021 10:30:24 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id l2so7102096wrw.6 for ; Tue, 01 Jun 2021 07:30:21 -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=lmXDuzCACof6H5k1oxJOF6yKQZD2tBhn0rCmH++UzqA=; b=MuppyqDSVTY8sFFYpKjwkRTpTDnDlizUlRWGUAAYsDP4J/e83IzkhlS4rcFy1U4wXZ 95W1kDqvA+gSSi0HdsDDKK6Tt9NLzGWwNAMKUPkZgPwm2YA6qBTdCfAwqSv6ycX2/uRD x1ELmHXRfn0PENbXd4MQpghC3HdJsqB9/Xzk7rIwwnfxF7jeeYovGbsBdaUlMQGQY4ZO amYimyzNSffPNvP3unWlv8l8DJMpq2AKp2s2IjdhKBEpIf3Q2Bz5XEzGPj5lHZh+GgKQ CTxRGoTZRH9QiUuqF6C5KpQOMxmMO9EeBnT7hTLaaAHLsjyCKHUc1o34u2d5m9Mufi1S E5uA== 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=lmXDuzCACof6H5k1oxJOF6yKQZD2tBhn0rCmH++UzqA=; b=lc7VDtQh0J7fFgw7mhgi6wp3Mb0hzUNLh66yU3Kk2qMZW82Xxoj/AgdFmzbXEM5IMT 3ENyy76juL9BB1R2YireB4b3FKXZac+mQ8l9mRMsB1rpyBw+LjQA7GMNmioSzPmYSyik v61vBG/Pqf7E3UyzTMxCdiduNF894Itth2co7o76nwVxF/Q+I+JKibencst7Fq78LJaW nNOVgBYkvbvSmFRFyjHaq42McRzpujbGmIF0ok0jluFUqvYF36AUcYbbcvPvkYRYjYlt bsGJ8r1nP7MwZn/IpthI29fdvBRPk+FeqKepUPSDtcbhu0nvYeFL8SNJA2/a75pBtJbp tPaw== X-Gm-Message-State: AOAM532yaAtmq44dwyeBOvWwr4JEqI5G49+MM7PEapiXM8HFCIHeT/TK uDu8rirhR94EqV8wxBVkh/E= X-Google-Smtp-Source: ABdhPJwHCeTlRlc53O9fMo36rdx8RGnHSWFFTlRC1rdIiPjv0amoniyAlhCunV8Y2HkMuSaA9FatSw== X-Received: by 2002:adf:cd0e:: with SMTP id w14mr28047765wrm.46.1622557820442; Tue, 01 Jun 2021 07:30:20 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id f18sm2932361wrg.34.2021.06.01.07.30.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 07:30:19 -0700 (PDT) In-Reply-To: <1b73a130-204c-76fb-2b60-02b814aee0f0@daniel-mendler.de> (Daniel Mendler's message of "Tue, 1 Jun 2021 14:37:59 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x434.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:270196 Archived-At: Daniel Mendler writes: > On 6/1/21 2:00 PM, Jo=C3=A3o T=C3=A1vora wrote: >>> * I observed an issue with the last candidate with `icomplete-scroll=3D= t` >>> - The candidate is one line off the minibuffer screen. > Yes, I am using the newest master version. But the issue seems to be > related somehow to my configuration, since I don't see it with emacs -Q. > I have to investigate which setting does this. Let me know about your findings. >>> * Do you plan to support the `group-function`? >>=20 >> Maybe, but nothing in Emacs uses it so I can't test. You can add it >> too, of course.=20 > > There is `read-char-by-name` one can use for testing. Juri added the > `group-function` there. I didn't know how to use it, so I just M-: (read-char-by-name "thingy"). It worked decently, I guess, but I couldn't find any evidence of "grouping". What is the group function supposed to do here? Does Vertico use it? What does it do with it? >> I don't understand one thing about that protocol: why >> the extra TRANSFORM argument flag? Why not just have that function >> return a tuple with the group title and transformed name? > > The design of the `group-function` has been extensively discussed. The > flag is used instead of a tuple for performance reasons. The computation > of the transformed candidate string may require string allocations, > which are expensive if performed for every candidate. That's right, I see your point. They could return a lambda, which is cheap to allocate, to defer the calculation. Or just nil or #'identity if it's supposed to stay unchanged. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index ec21b7b93b..5c00e7bb81 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1450,11 +1450,14 @@ minibuffer--group-by "Group ELEMS by GROUP-FUN and sort groups by SORT-FUN." (let ((groups)) (dolist (cand elems) - (let* ((key (funcall group-fun cand nil)) + (let* ((key-and-transform (funcall group-fun cand)) + (key (car key-and-transform)) (group (assoc key groups))) - (if group - (setcdr group (cons cand (cdr group))) - (push (list key cand) groups)))) + (cond (group + (put-text-property 0 1 'completion--transform (cdr key-a= nd-transform) + cand) + (setcdr group (cons cand (cdr group)))) + (push (list key cand) groups)))) (setq groups (nreverse groups) groups (mapc (lambda (x) (setcdr x (nreverse (cdr x)))) The protocol is slightly simpler since it returns the same type every time. More importantly, this avoids threading group-fn down a bunch of functions in minibuffer.el, where it seems to be adding an awful lot of complexity. Jo=C3=A3o