From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
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: Sat, 21 Aug 2021 15:01:06 +0300 [thread overview]
Message-ID: <54ad79de-d527-0462-edaa-eee56c724565@yandex.ru> (raw)
In-Reply-To: <878s0vqgny.fsf@gmail.com>
On 21.08.2021 12:40, João Távora wrote:
> Some tables and grouping strategies, like the xref table, seem to be
> "naturally" grouped by the way you harvest candidates. For others, we
> could make just make it so that they are. That "make it so" wouldn't
> necessarily mean calling `group-function` for every candidate.
Whether it's called for every candidate, is a UI/design choice.
>> The cost of the grouping function doesn't matter when making this
>> choice.
>
> Yes, I think you see what you mean. But I also imagine it would be
> terrifyingly confusing for a user of a scrolling dropdown to see
> candidates jump back and forth into their groups as the user scrolls
> down to see a new candidate and hide another. If what I imagine isn't
> what you mean, maybe you could code something up and show what you mean.
I suppose yes, if you only group candidates that are visible on the
screen, it could lead to jumping. Good point. Then I would suggest to go
back to "global" grouping.
>>> You suggestion, as far as I can see, has none of these three elements.
>>> So if you or someone else wants to experiment with the re-grouping (with
>>> whichever implemention),
>>
>> Why do you call it re-grouping? Grouping happens after sorting, there
>> is no prior grouping step.
>
> For example, in xref.el the matches provided by the completion table
> are, IIUC, already "naturally" grouped, because they are collected file
> by file, and the file is the group. That grouping is then completely
> destroyed by a+l+r sorting. Your proposal would, I presume, destroy
> that sorting to restore grouping. Hence "re-group".
I see.
The order of completions coming from xref is essentially random. Yes,
they are grouped by files (usually), but the files are not coming in any
particular order. So I would prefer not to skip the sorting step.
Of course, there might be different scenarios and preferences in that
regard.
> Note that I previously assumed, mistakenly, that the entries in C-x 8
> RET were also naturally grouped. They're not. They could very easily
> be, and with no performance penalty.
>
>>>>> 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.
>>>> Right. I just don't think either is costly, most of the time.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Did you read my previous message where I reported that C-x 8 RET
>>> currently takes about a second to compute completions and only 0.6
>>> seconds when sorting is removed?
>> I was talking about the grouping step, obviously. Not being costly.
>
> You wrote "I just don't think either is costly".
Okay. Sorting seems to indeed be costly in this case (if I trust your
measurements).
Sorting is part of the default completion behavior (with grouping or
not). You want to remove it instead of fixing?
>> Try disabling grouping. Is completion still slow? Then it's a problem
>> with sorting speed that needs to be solved separately anyway.
>
> icomplete.el doesn't do any grouping, it merely prints the grouping
> information as headers for the few matches that it will print.
> completion-all-sorted-completions also doesn't care about grouping. So
> there's nothing to disable in that regard.
That addressed 3 words out of 20.
>>> This is flex doing its thing.
>> Yup. This is what I suggested to change.
>
> As I explained two or three times now: you can. In a new dmitry-flex
> style. That style is only a few lines of code away, I suppose. Or a
> defcustom, if you prefer those. The current behaviour for 'flex' is the
> correct one. It was conceived like this. flex scoring trumps grouping,
> table orders, etc... If you don't like this you can change this, like
> everything in Emacs.
Nothing I suggested should call for a change in completion style.
next prev parent reply other threads:[~2021-08-21 12:01 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
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 [this message]
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=54ad79de-d527-0462-edaa-eee56c724565@yandex.ru \
--to=dgutov@yandex.ru \
--cc=48545@debbugs.gnu.org \
--cc=joaotavora@gmail.com \
--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.