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

Previous Next

Full log

Message #34 received at 48545 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: mail <at> daniel-mendler.de, 48545 <at> debbugs.gnu.org
Subject: Re: bug#48545: 28.0.50; `icomplete-vertical-mode` does not support
 the `group-function`
Date: Thu, 19 Aug 2021 20:41:38 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 19.08.2021 14:18, João Távora wrote:

>> completion-all-sorted-completions in minibuffer.el if a table supplies
>> `group-function`.  A patch for this is after my sig.
>
> We discussed this problem when group-function was introduced. Another
> approach is to just change the method of grouping: first the
> completions are sorted, and then they are sorted into groups.

That's a possiblity. But it might be performing too much work, at least
at first sight.  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.

I recommend whatever is done that some quantitative benchmarking is
performed to the before/after.  Enabling fido-vertical-mode and pressing
C-u C-x C-e C-m after

   (benchmark-run (call-interactively 'insert-char))

Seems to be a decent way to measure.

Currently, with the alpha/length/history sorting, it takes about 1
second in my machine.  Without any sorting (and the natural grouping),
takes about 0.6 seconds.  You should measure what the re-grouping
sorting does.

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.