bug#48545: 28.0.50; `icomplete-vertical-mode` does not support the `group-function`

[Dmitry Gutov <dgutov@yandex.ru>]

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.