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 16:49:55 +0100 Message-ID: <878s3t8tzw.fsf@gmail.com> References: <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> <87r1hl8xom.fsf@gmail.com> 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="1474"; 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 17:50:47 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 1lo6fH-0000EU-0S for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 17:50:47 +0200 Original-Received: from localhost ([::1]:36570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo6fG-0007HK-3W for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 11:50:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo6eX-0006Kd-Be for emacs-devel@gnu.org; Tue, 01 Jun 2021 11:50:01 -0400 Original-Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:36709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lo6eV-0001KK-H8 for emacs-devel@gnu.org; Tue, 01 Jun 2021 11:50:01 -0400 Original-Received: by mail-wm1-x329.google.com with SMTP id n17-20020a7bc5d10000b0290169edfadac9so1911859wmk.1 for ; Tue, 01 Jun 2021 08:49:58 -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=eo/BEr0lUPCqrb+htp6BKkAgEB8/CqksbBAJhZgC9Tc=; b=uhrjY2Vt+n3phnsBH1khqdUaldX95DYpK7VmfsoF1YJOqD6D/HVwio2Xp3Qzx0PVOk tG6WiMYPwa5PT92xAXBcEVGzclOYxTiz9jRU0svpvDZ2mWUMw9kaLskM3ZilAjwoFSV2 4FM81uX59LzGT3nQfqbGMidmqLGvWPQiPsrd8haX0Vi+51rSJRGnw11IoiNhSvjFN+ER GtgKgryK+VMieGN+IUr0yBtRAxMV1r8j4aF0QtYllr320RcbxnZqNXBVug8YStUHa5gV mq8zKk7uHlrPsp3pMD/X8Y3HgyULBp4HtfV6ixmThn3OE46QwKTFeSsESJdNWa0zlOqF 3NrQ== 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=eo/BEr0lUPCqrb+htp6BKkAgEB8/CqksbBAJhZgC9Tc=; b=sZmNfrFEEcEoYXkaHni61Em2h+Pga0+/poGfn+qUAK7V/36GP32BR1/pFupDPOV+Rd XOY9kRLMQpxmjeDQtrnJSnayehxai/CNWUD42vlWioSiUGENLmYmptKpB+bzu6bck4p4 yeC49WT+Zi91Nl+4DQdkFzO5cCsUkIC1uVc4j13cJSiJlzk0Zg2XU9cEQUQtdXHei4Ax FQ7kTqdxADjJnJfybDse1wk4UsFkKnFZCZdHbxGfoPOcHtPVrw05P2UjNzUt2BCwU6iM HQbSp+4pUQJ/rRJai+F9ecOyTol79hTI8HRzi5WUo5kFJPCHV3JjXZCewoa9Ac8aZj/8 A2cw== X-Gm-Message-State: AOAM532eK7+KAx/RO7uaOz8HDrFNJlaHT/Z8NVxdV5tIpBems3TFo+WI YExJYndky5p1I2Hnl42saLA= X-Google-Smtp-Source: ABdhPJxAUr25UoTId0G90jevwxEdx4IhPhFdK/aLs0bl7P34dALVd+BqE9LxlWeCzVB1PTE8XokAAg== X-Received: by 2002:a05:600c:2209:: with SMTP id z9mr27391242wml.120.1622562597403; Tue, 01 Jun 2021 08:49:57 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id r2sm3722216wrv.39.2021.06.01.08.49.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 08:49:57 -0700 (PDT) In-Reply-To: (Daniel Mendler's message of "Tue, 1 Jun 2021 16:40:17 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::329; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x329.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:270212 Archived-At: Daniel Mendler writes: > On 6/1/21 4:30 PM, Jo=C3=A3o T=C3=A1vora wrote: >>> 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. >>=20 >> That's right, I see your point. >>=20 >> 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. >> ... >> 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. > > No, I am against changing the group function. I am using this efficient > definition in my packages and I rely on the performance > characteristics. But do you have any evidence to suggest that making a cons and allocating a function is detrimental to this?? I just tried this small patch to the function you suggested as a potential hog, since it iterates all the completions. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index ec21b7b93b..32737ff1ce 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -1450,11 +1450,15 @@ 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* ((pair (cons (funcall group-fun cand nil) + (lambda () (list "oh no a capture" + cand)))) + (key (car pair)) (group (assoc key groups))) (if group (setcdr group (cons cand (cdr group))) - (push (list key cand) groups)))) + (push (list key cand) groups)) + (put-text-property 0 1 'transform (cdr pair) cand))) (setq groups (nreverse groups) groups (mapc (lambda (x) (setcdr x (nreverse (cdr x)))) (length joaot/test); 44547 taken from the `read-char-by-name' table (benchmark-run 10000000 '(minibuffer--group-by #'mule--ucs-names-group ; group-fn of that table #'identity joaot/test)) =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ;; Before the patch ;; ;; (0.10353484400000001 0 0.0) ;; (0.08804328700000008 0 0.0) ;; (0.11191811499999996 0 0.0) ;; ;; After ;; ;; (0.09785707300000002 0 0.0) ;; (0.10107326400000005 0 0.0) ;; (0.09778669299999998 0 0.0) So basically the same. Cons and lambda's are cheap. Also, for good measure, I also changed that function to allocate a 30 char string for each completion (instead of the lambda). Also quite snappy (though there's maybe an effect showing). ;; (0.10938493999999999 0 0.0) ;; (0.10871186500000007 0 0.0) ;; (0.11186114000000003 0 0.0) > The current implementation is simple enough and also avoids allocation > of the cons pair and the allocation of the lambda as in your proposal. > The efficiency is crucial here. I believe you, but I haven't seen any evidence (yet) to back up the claim. But instead of me whistling premature optimization song, feel free to point me to some numbers or something. > Furthermore I argue that the current implementation is simpler to > understand for the completion table authors than your counter > proposal, which introduces a deferred computation with the lambda. It's like the affixation-function thing, I don't think it makes sense for client code to do these IFs, much as I dont' think it makes sense for them to do MAPCARs. But to be clear, the main advantage here in my opinion is the cleanup in minibuffer.el, which is somehwat messy in my opinion (not only from group-fn's fault, of course). > There was a long discussion with Stefan, Dmitry, Juri and Eli where > multiple different designs for the `group-function` have been considered > and we settled on the current design. It could have been discussed with your favourite divinity, for all I care. If I see something worthy of improvement for the next version, I'm going to suggest it here. Especially in the case of a new feature in master. "It's been discussed with so and so" is not a worthless argument, but it's not very valuable either. Jo=C3=A3o