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

Previous Next

Full log

Message #49 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: Daniel Mendler <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: Sat, 21 Aug 2021 01:24:47 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 20.08.2021 02:39, João Távora wrote:

> icomplete's grouping behavior should probably match the default UI's
> behavior in that regard. Or, if people actually don't like it, see it
> changed in both places.

Because it was fairly easy to, i tested the default UI with grouping and
C-x 8 RET.  It seems that it doesn't use
completion-all-sorted-completions, and hence doesn't do the normal
alphabetical+length+recency sorting (let's call it a+l+r from now on) at
all by default.  It does do the re-grouping though.  And it takes a long
time, about 3-4 seconds (when one presses TAB at the prompt) to see the
first page of the completions list.

This is versus Icomplete which about a second  (or even less if
you skip the a+l+r).

So whatever the default completion UI does, I don't think Icomplete
should imitate it if it means the same slow behaviour.

The default UI can do some sorting on top of regrouping if you set yet
another variable completions-group-sort, but then it will be only
alphabetical, not a+l+r.  No idea why.

However, I've also discovered that my previous assumption that C-x 8 RET
returns naturally grouped chars is also wrong.  They are _not_ naturally
grouped.

João

Previous Next

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