From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Date: Fri, 20 Aug 2021 00:39:29 +0100 Message-ID: References: <10d162d5-2cd6-dd87-3289-a0187dfbf51f@daniel-mendler.de> <871r6sw9iz.fsf@gmail.com> <87a6lfnld0.fsf@gmail.com> <87eearulft.fsf@gmail.com> <871r6pr8bk.fsf@gmail.com> <54e4e409-5525-b796-9e9c-582735995cc1@yandex.ru> <87r1epp6h9.fsf@gmail.com> <266d8a54-90de-e904-f548-8ec29e52923c@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009c90b605c9f2106a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , 48545@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 20 01:40:20 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mGre0-0005BY-Cn for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Aug 2021 01:40:20 +0200 Original-Received: from localhost ([::1]:59670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGrdy-0000wc-VY for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 19 Aug 2021 19:40:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGrdi-0000vo-JR for bug-gnu-emacs@gnu.org; Thu, 19 Aug 2021 19:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mGrdi-0007M3-Ba for bug-gnu-emacs@gnu.org; Thu, 19 Aug 2021 19:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mGrdi-0001Pb-13 for bug-gnu-emacs@gnu.org; Thu, 19 Aug 2021 19:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 23:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48545 X-GNU-PR-Package: emacs Original-Received: via spool by 48545-submit@debbugs.gnu.org id=B48545.16294163895406 (code B ref 48545); Thu, 19 Aug 2021 23:40:01 +0000 Original-Received: (at 48545) by debbugs.gnu.org; 19 Aug 2021 23:39:49 +0000 Original-Received: from localhost ([127.0.0.1]:60952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGrdV-0001P7-E7 for submit@debbugs.gnu.org; Thu, 19 Aug 2021 19:39:49 -0400 Original-Received: from mail-pg1-f178.google.com ([209.85.215.178]:36551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGrdT-0001Ow-Bb for 48545@debbugs.gnu.org; Thu, 19 Aug 2021 19:39:48 -0400 Original-Received: by mail-pg1-f178.google.com with SMTP id t1so7415742pgv.3 for <48545@debbugs.gnu.org>; Thu, 19 Aug 2021 16:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UzoCgnCKTH/14P8JDvfq5m39jMwDyvGUKnVuafg4ZU4=; b=ehqcnknBuzGc/Qlf0Czo1rrDPoe7bbnTAO9F+2X8SBMEQiajFnmQee4C1rpma7IdMS ZeaISVhpfdKdKm2G9y2KF+qghVbEZb4/+iPR0xJbMczqU5gZSsuBsjZN0IbMl1JO7CMw 6vzjz+j8KAP4Td/jByK92OYOz8jsE3v0cKAOEtRLMX56ZaQ/AcRGp/iPp3tbyM5E9NYa LkaPKOOMIQ0WrWVgqEBdlUYExU5t3jJsm0hhPdN0ruEFO7LxkqULKqp7c9VMUMX8T6yi JSRvoYyWKEc4kXfeeedPAWi+42YRXxsDSvfRqpWp55guKHcCjGBd7CdJfYZm4q8i/mC/ LEKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UzoCgnCKTH/14P8JDvfq5m39jMwDyvGUKnVuafg4ZU4=; b=T8C/YyXvJj8TB4CNwsy5lxKAV1yO8QiRFr7TLmcMB9LrYKdq8MLz+CRh+qWZDAUkdw UXy8U0M4VK6V3Fn5ECYZ8bGEQnX9E8FV1DyX9QwuBFbgGc+VMYUklVYUi+YT/igL/9e1 WKGIra20M1pEpG5KXsFfs47A1C4xrGyVbRKRUp3/CG8u8oXZ3om0cWiffi4Pv6o1x3lN tUGu3C7K9daLUxmbzxWefS6S3a3cQ10zJKd06t10INMK7h8wJEUirb4fpj+1+bz/KkRe 7sb2g9697QMStxELwn2O26wTBp1QX+54WnhZNBsZ/HTVWEN1Omcr9tNzojpERygBka1V GJqQ== X-Gm-Message-State: AOAM5326qrLC9b0rJNsdxkGw6x7cY3IhNvT2lEmKYtc6R2O8Qf5XnPSu P+OnLp39eQarCdlJJffwe8MFgzdbsCwJ4uJbmj8= X-Google-Smtp-Source: ABdhPJzMVOcHXT7JESPHW5OzYhGrKNX8CCxpgNYsl6gRzGdoHyO88hgtja6Ptmx8HopqkxvUULj5yIOS0ANtuhmm+Qw= X-Received: by 2002:a63:c0a:: with SMTP id b10mr16021913pgl.447.1629416381516; Thu, 19 Aug 2021 16:39:41 -0700 (PDT) In-Reply-To: <266d8a54-90de-e904-f548-8ec29e52923c@yandex.ru> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:212243 Archived-At: --0000000000009c90b605c9f2106a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 19, 2021, 23:37 Dmitry Gutov wrote: > On 19.08.2021 22:41, Jo=C3=A3o T=C3=A1vora wrote: > > > That's a possiblity. But it might be performing too much work, at least > > at first sight. > > Not sure I understand. Grouping is a linear operation, isn't it? O(N). > Which is generally cheaper than the sorting step that came before. > Yes, but you'd be adding to it and that is always worse than _not_ adding to it. And there's a constant factor in front of that O(N). So that's why I think measurements should be taken, always. Not to mention that if the table is already "naturally" grouped upfront, your're incurring in both the sorting cost and the grouping cost, when you could just be skipping both with little to no downsides, I would presume. Of course, maybe I presume wrong, but K=C3=A9vins report, who does use completions-group, seems to confirm it. > For the C-x 8 RET case and the xref table (the only > > tables I know which use this) things seem to be naturally put into > > groups already. So sorting them alphabetically, by length, by history, > > and _then_ destroying most (but not all) with the grouping could be not > > so interesting if the there's a big a price to pay. > > Could be it misses information. > ? Don't understand this... OTOH, if you split completions belonging to the same group apart, you > can end up with a list where there as as many group headers, as there > completions (in the extreme case). > That's true. That's why my idea is to skip sorting altogether when tables have a group-function, under the assumption that good speed matters much more than applying the default sorting within each group. For example, what does it matter to have a recently chosen UTF-8 completion bubble up to the top of a group that's buried deep down in the long list of groups? Not much, I think. And largely the same for the length and lexicographical sorting. I'd even venture to say it's like this for any table with a group-function, though I only know two such tables. And that's why I proposed that generic minibuffer.el patch. But, the alternative, to do it per table, could also be fine and is reasonably short, too. What behavior does (setq completions-group t) have? Seems to be a flag that controls the presence of 'group-function' in some tables. Can't speak of the other UIs, but icomplete just honors 'group-function' and does not double check the flag. It could, if it were relevant, I guess. It affects the default UI, IIUC. Yes, I believe so. But what is the relevance? Jo=C3=A3o --0000000000009c90b605c9f2106a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 19, 2021, 23:37 Dmitry Gutov <dgutov@yandex.ru> wrote:
On 19.08.2021 22:41, Jo=C3=A3o T=C3=A1vora wrote:=

> That's a possiblity. But it might be performing too much work, at = least
> at first sight.

Not sure I understand. Grouping is a linear operation, isn't it? O(N).<= /blockquote>

Which is generally cheaper than the sorting step that came before.

Yes, but = you'd be adding to it and that is always worse than _not_ adding to it.= And there's a constant factor in front of that O(N). So that's why= I think measurements should be taken, always.

<= /div>
Not to mention that if the table is already "na= turally" grouped upfront, your're incurring in both the sorting co= st and the grouping cost, when you could just be skipping both with little = to no downsides, I would presume.

Of course, maybe I presume wrong, but K=C3=A9vins report, who doe= s use completions-group, seems to confirm it.=C2=A0=C2=A0

> For the C-x 8 RET case and the xref table (the only
> tables I know which use this) things seem to be naturally put into
> groups already.=C2=A0 So sorting them alphabetically, by length, by hi= story,
> and _then_ destroying most (but not all) with the grouping could be no= t
> so interesting if the there's a big a price to pay.

Could be it misses information.

? Don't understand this...

OTOH, if you split completions belonging to the same group apart, you
can end up with a list where there as as many group headers, as there
completions (in the extreme case).

That's true. That's why my idea i= s to skip sorting altogether when tables have a group-function, under the a= ssumption that good speed matters much more than applying the default sorti= ng within each group.

Fo= r example, what does it matter to have a recently chosen UTF-8 completion b= ubble up to the top of a group that's buried deep down in the long list= of groups? Not much, I think. And largely the same for the length and lexi= cographical sorting.

I&#= 39;d even venture to say it's like this for any table with a group-func= tion, though I only know two such tables. And that's why I proposed tha= t generic minibuffer.el patch. But, the alternative, to do it per table, co= uld also be fine and is reasonably short, too.

<= /div>
What behavior does (setq completions-group t) have?=C2=A0

Seems to be a flag that controls the presence of 'group-function'= in some tables. Can't speak of the other UIs, but icomplete just honor= s 'group-function' and does not double check the flag. It could, if= it were relevant, I guess.


Yes, I believe so. But what is the = relevance?
=
Jo=C3=A3o

--0000000000009c90b605c9f2106a--