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 23:32:27 +0100 Message-ID: <87tumh6wsk.fsf@gmail.com> References: <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> <878s3t8tzw.fsf@gmail.com> <3c68bd00-70ca-fa18-f9b8-cd03029f9294@daniel-mendler.de> <8735u18lsd.fsf@gmail.com> <4649e8f9-7ac2-1d5e-5a44-90e470d6d2ad@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="35938"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: "emacs-devel@gnu.org" , Dmitry Gutov , monnier@iro.umontreal.ca, Juri Linkov To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 00:33:35 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 1loCx5-00099L-8b for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 00:33:35 +0200 Original-Received: from localhost ([::1]:41364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loCx3-0005IS-Uu for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 18:33:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41462) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loCwJ-0004bq-GP for emacs-devel@gnu.org; Tue, 01 Jun 2021 18:32:47 -0400 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:44996) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loCw7-0007n1-Pf for emacs-devel@gnu.org; Tue, 01 Jun 2021 18:32:46 -0400 Original-Received: by mail-wr1-x436.google.com with SMTP id f2so192753wri.11 for ; Tue, 01 Jun 2021 15:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=HZY9I1XHDxfKp1QA1fFwRFXl0GIGy7NUCFgYgpuFWXk=; b=bffq/E4cxIkw+jl2Mw0gWM1hW8kdDvx0tJ6olveorUcC01/t0NgvtQTUmSiiRX7/lx 09E+PwLZThs9lRUHEqlvvrOAv+91+ufcPGvJrcc50EIUGi5a3XfiZtggLDsIRpzJPJEH wQiAMY4hYQAspaiQaI12nT9lodJHoIHsagYT5Qb/xCDc/O2OAmKobbYt/dUZbj+6ytAz KAty2TmqQF3l/Pct5/hDkPN/HmIqSM6vYpa7Ugj4uF3ra2rZftHUw6QEXZBDeB2kcY36 thVRcu8ykvOw4h5o2BE470JzRJsfsLVuhQ0mD8iwRcvCwfLzlbT7mT0hgDS1VlDkI3l7 NWhg== 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:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=HZY9I1XHDxfKp1QA1fFwRFXl0GIGy7NUCFgYgpuFWXk=; b=NYB8AncsAShxX02uO6a/KZmTIbQ+HfkC1psFSIQQR+gN1zoboUZaf+M9I7jK43+VtB jqgBV+l7BIi01inOJ0h/TtnznhAhSWat51xmH0TT6/JfLqLBmrxEGkxh27lPX2hf9OmI 6at5uZFNey2EI/AUbPpVWqq3j04HhzucVM0pP150QIwVfvLrTVOLf8wogxD605Kg62n+ EtBMO2+bcpL3A9SovrEHXkCxxqgXTceqF19HZz7iJQH4SAh5dGsnK366MvBOgfKppgVU vEsOYqfI2w8zqz3+H61SXKD/1jG9xZX7Cgjc6pe1N9tniPoWNt0UBHDV67ONZ97agO1V ikKA== X-Gm-Message-State: AOAM531vMIpYTbN+z9t5G3bKIQ8jhbM1hCAIvOYF8DxOygpbwocFkkIK eWI5cOVwdv2pCykEGRPnCj8= X-Google-Smtp-Source: ABdhPJygqBPwqAo+uMt39562xeNcGCF21WzThgilawgTPGxE3+gapbFR8stFWFQ6nzo763PwHM1uNg== X-Received: by 2002:adf:ce90:: with SMTP id r16mr23761974wrn.146.1622586750336; Tue, 01 Jun 2021 15:32:30 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id a11sm4526681wrr.48.2021.06.01.15.32.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 15:32:29 -0700 (PDT) In-Reply-To: <4649e8f9-7ac2-1d5e-5a44-90e470d6d2ad@daniel-mendler.de> (Daniel Mendler's message of "Tue, 1 Jun 2021 21:03:12 +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=unavailable 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:270255 Archived-At: Daniel Mendler writes: > On 6/1/21 8:47 PM, Jo=C3=A3o T=C3=A1vora wrote: >> I really doubt this "matters when scrolling", as grouping would be >> called once per filtering, and scrolling is just getting at each >> candidate's transform. If anything, if you take the last option, it >> could _speed up_ scrolling (and the cost of some more initial latency). > Yes, you are right about that. It matters when refiltering the candidate > list, which happens quite often in Vertico or other continuously > updating UIs. Indeed, and losing 20 seconds (example above) for each refiltering is normally prohibitive. That's why icomplete (and probably all these other ui's have while-no-input), effectively interrupting the processing. So it also doesn't matter when rapidly typing. It's only when the user "settles" on a value. >> I've told you the point. A simpler minibuffer.el code, possibly with >> less branching and logic, which might even be faster. > I doubt that you manage to make it simpler. If you indeed manage to > make [it] simpler I will propose a counter patch based on the current > definition which is as simple. If I or you or anyone else manages to make X or Y simpler, we judge that work based its merits and drawbacks. Tends to work better. > There is also no need to rediscuss a fine solution without making a > better and proper counter proposal. My proposal's merits are a simpler protocol and simplified minibuffer.el. Its drawbacks are what I think are a negligble performance hit in non-essential scenarios. You may not agree with this assessment, but there's nothing "improper" about it. > I have made many material arguments and you ignore them. A bizarre claim: you pointed to performance loss and to a specific function that iterates all completions, and I spent the effort to look at that function, benchmark variations on it and share my results with you. I found that even with a very large set of completions only a small amount of time is lost (around 3-5%) even if you happen hit an unlucky GC. Sure you may think that's unacceptable. But when? In what circumstances? For example, you once said it "matters when scrolling", but then we established that it doesn't. > I benchmarked this heavily in my Vertico UI. So I can assure you that I > looked into this. I rely on this for the performance of Vertico and for > the performance of other continuously updating UIs. I'd rather learn details of those experiments and their results. The only thing I have are measurements and methodology that I shared with you and which don't point to anything serious. Jo=C3=A3o