From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Daniel Mendler <mail@daniel-mendler.de>, 48545@debbugs.gnu.org
Subject: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function`
Date: Fri, 20 Aug 2021 00:39:29 +0100 [thread overview]
Message-ID: <CALDnm51taxxujsqHg77QuM=2Hd3GuXYgSKqqX3NGXXgTNXVzSQ@mail.gmail.com> (raw)
In-Reply-To: <266d8a54-90de-e904-f548-8ec29e52923c@yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]
On Thu, Aug 19, 2021, 23:37 Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 19.08.2021 22:41, João Távora 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évins 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ão
[-- Attachment #2: Type: text/html, Size: 4856 bytes --]
next prev parent reply other threads:[~2021-08-19 23:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 18:56 bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function` Daniel Mendler
2021-08-17 12:17 ` João Távora
2021-08-18 9:38 ` Kévin Le Gouguec
2021-08-18 9:55 ` João Távora
2021-08-19 11:18 ` João Távora
2021-08-19 12:38 ` Kévin Le Gouguec
2021-08-19 13:29 ` João Távora
2021-08-19 19:36 ` Kévin Le Gouguec
2021-08-19 15:02 ` Dmitry Gutov
2021-08-19 19:41 ` João Távora
2021-08-19 22:37 ` Dmitry Gutov
2021-08-19 23:39 ` João Távora [this message]
2021-08-19 23:51 ` Dmitry Gutov
2021-08-20 10:35 ` João Távora
2021-08-21 2:09 ` Dmitry Gutov
2021-08-21 9:40 ` João Távora
2021-08-21 12:01 ` Dmitry Gutov
2021-08-21 12:42 ` João Távora
2021-08-22 13:52 ` Dmitry Gutov
2021-08-22 15:44 ` João Távora
2021-08-21 0:24 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALDnm51taxxujsqHg77QuM=2Hd3GuXYgSKqqX3NGXXgTNXVzSQ@mail.gmail.com' \
--to=joaotavora@gmail.com \
--cc=48545@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=mail@daniel-mendler.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.