GNU bug report logs - #29833
icomplete re-build the completion table after each key press

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29833 in the body.
You can then email your comments to 29833 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Shuguang Sun <shuguang <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: icomplete re-build the completion table after each key press
Date: Sun, 24 Dec 2017 16:58:28 +0800

[Message part 1 (text/plain, inline)]

Hi,

The icomplete re-build the completion table
'completion-all-sorted-completions' after each key press. However, I think
it should keep the 'completion-all-sorted-completions' builded at beging
and re-use it afterwise.

At least in Windows, GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of
2017-12-09.

How to repeat it:
1: emacs -q
2: icomplete-mode (we can't find anything wired unless we call
dired-do-copy on a network-mapped remote file under a slow network)
3: modify function icomplete-exhibit to log as below:
    insert '(print completion-all-sorted-completions)' between
'(save-excursion  (goto-char (point-max))' and '(if (and (or
icomplete-show-matches-on-no-input', and C-M-x.
    Then it will print 'nil' after each key press which means
'completion-all-sorted-completions' is empty.
4. modify function icomplete-completions to log as below:
    insert '(print completion-all-sorted-completions)' at the begining of
the function body, prior to "(let* ((minibuffer-completion-table
candidates)'.
    Then it will print 'nil' after each key press which means
'completion-all-sorted-completions' is empty.

Thereby, it has to call "(comps (completion-all-sorted-completions
(icomplete--field-beg) (icomplete--field-end)))' in function
icomplete-completions to re-build the completiong table after each key
press.

Thanks *Stefan Monnier *to point out it should be a bug in the help
maillist.

By the way, '(sequencep (icomplete--completion-table))' in function
icomplete-exhibit always returns 'nil', and the
icomplete-delay-completions-threshold actually has no effect.
(print (icomplete--completion-table)) just returns the table name (function
to generate the table), but not the content of the table.

By the way again, if call dired-do-copy or dired-do-rename,
icomplete-max-delay-chars counts the whole path of the file because, the
path has been put to the minibuffer automatically. This may not a bug,
however, I think it should be documented.


Best Regards,
Shuguang Sun

[Message part 2 (text/html, inline)]

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

From: Shuguang Sun <shuguang <at> gmail.com>
To: shuguang <at> gmail.com, bug-gnu-emacs <at> gnu.org
Subject: bug#29833: icomplete re-build the completion table after each key
 press
Date: Mon, 25 Dec 2017 22:40:51 +0800

[Message part 1 (text/plain, inline)]

For reference: If icomplete-mode is on, it has the same issue with
counsel-find-file
(from swiper/counsel, https://github.com/abo-abo/
swiper/blob/master/counsel.el). After typeing each key, it will try to
re-build the file list. If turning icomplete-mode off, it will act as ido
and will not re-build the completion list.

Best Regards,
Shuguang

[Message part 2 (text/html, inline)]

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

From: Shuguang Sun <shuguang <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: icomplete re-build the completion table after each key press
Date: Sat, 6 Jan 2018 15:27:27 +0800

[Message part 1 (text/plain, inline)]

Dear Emacs developers:

I tired to find out the issues and provide patches to minibuffer.el and
icomplete.el.

What is the issue?
1. The function completion--flush-all-sorted-completions defined in
minibuffer.el is always called without parameters which make it flush the
cached table every time.
2. The function completion--flush-all-sorted-completions is added to the
hook of after-change-functions, however, (jit-lock-after-change t) in the
hook will trigger flush every time
3. The local cached table completion-all-sorted-completions is not used
actually. The minibuffer-completion-table is called in a lot of function
which will rebuild the table instead of the chached table.

It has small impact on the performance of
1. operation in memory, e.g., describe-variable, describe-function
2. filename in local driver/PC
3. filename in tramp where it works on the ls output instead of trying to
re-do the ls command on the server
Those operations are fast and time for fuctions symbolp and functionp is
ignorable.

However, if it works under some slow instance, for example, a mapped driver
in Window with slow net work, the performance is bad as the completion
tries to list the directory in each call of completion--do-completion and
icomplete-completions, and some other completion functions.

The patches try to use the cached table
completion-all-sorted-completions-table as much as possible, and for
filename completion, it caches the list of files in the base directory
(file-name-directory).
https://github.com/ShuguangSun/emacsimprovement/tree/master/bug%2329833









On Sun, Dec 24, 2017 at 4:58 PM, Shuguang Sun <shuguang <at> gmail.com> wrote:

> Hi,
>
> The icomplete re-build the completion table 'completion-all-sorted-completions'
> after each key press. However, I think it should keep the
> 'completion-all-sorted-completions' builded at beging and re-use it
> afterwise.
>
> At least in Windows, GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of
> 2017-12-09.
>
> How to repeat it:
> 1: emacs -q
> 2: icomplete-mode (we can't find anything wired unless we call
> dired-do-copy on a network-mapped remote file under a slow network)
> 3: modify function icomplete-exhibit to log as below:
>     insert '(print completion-all-sorted-completions)' between
> '(save-excursion  (goto-char (point-max))' and '(if (and (or
> icomplete-show-matches-on-no-input', and C-M-x.
>     Then it will print 'nil' after each key press which means
> 'completion-all-sorted-completions' is empty.
> 4. modify function icomplete-completions to log as below:
>     insert '(print completion-all-sorted-completions)' at the begining of
> the function body, prior to "(let* ((minibuffer-completion-table
> candidates)'.
>     Then it will print 'nil' after each key press which means
> 'completion-all-sorted-completions' is empty.
>
> Thereby, it has to call "(comps (completion-all-sorted-completions
> (icomplete--field-beg) (icomplete--field-end)))' in function
> icomplete-completions to re-build the completiong table after each key
> press.
>
> Thanks *Stefan Monnier *to point out it should be a bug in the help
> maillist.
>
> By the way, '(sequencep (icomplete--completion-table))' in function
> icomplete-exhibit always returns 'nil', and the icomplete-delay-completions-threshold
> actually has no effect.
> (print (icomplete--completion-table)) just returns the table name
> (function to generate the table), but not the content of the table.
>
> By the way again, if call dired-do-copy or dired-do-rename,
> icomplete-max-delay-chars counts the whole path of the file because, the
> path has been put to the minibuffer automatically. This may not a bug,
> however, I think it should be documented.
>
>
> Best Regards,
> Shuguang Sun
>

[Message part 2 (text/html, inline)]

[minibuffer.el.patch (application/octet-stream, attachment)]

[icomplete.el.patch (application/octet-stream, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Shuguang Sun <shuguang <at> gmail.com>
Cc: 29833 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#29833: icomplete re-build the completion table after each
 key press
Date: Mon, 21 Sep 2020 16:27:38 +0200

Shuguang Sun <shuguang <at> gmail.com> writes:

> I tired to find out the issues and provide patches to minibuffer.el and icomplete.el.
>
> What is the issue?
> 1. The function completion--flush-all-sorted-completions defined in minibuffer.el is
> always called without parameters which make it flush the cached table every
> time.
> 2. The function completion--flush-all-sorted-completions is added to the hook of
> after-change-functions, however, (jit-lock-after-change t) in the hook will trigger
> flush every time
> 3. The local cached table completion-all-sorted-completions is not used actually.
> The minibuffer-completion-table is called in a lot of function which will rebuild the
> table instead of the chached table.

[...]

> The patches try to use the cached table completion-all-sorted-completions-table as
> much as possible, and for filename completion, it caches the list of files in the base
> directory (file-name-directory).

This patch unfortunately got no response when it was posted two years
ago, and it no longer applies cleanly to Emacs 28.

I'm not very familiar with the completion functions, but I think your
changes make conceptual sense, at least.  Perhaps Stefan can provide
some feedback here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Shuguang Sun <shuguang <at> gmail.com>
Cc: 29833 <at> debbugs.gnu.org
Subject: Re: bug#29833: icomplete re-build the completion table after each
 key press
Date: Mon, 21 Sep 2020 13:47:20 -0400

> The icomplete re-build the completion table
> 'completion-all-sorted-completions' after each key press.

This is considered normal.
The reason is that icomplete can't know in general how to take the
list of matching completions for "foob" or for "fo" (or for any other
string for that matter) and compute the corresponding list of
matching completions.

This is because it depends on lots of details.  E.g. when completing
files when going from "foo" to "foo/" the list of completions is
completely changed.  In other cases, "foo" matches something using
a particular completion-style but "foob" doesn't, so a different
completion-style will be used, ...

It is true that in many case the completions of "foob" are a subset of
the completions of "foo", so we could recompute them faster but
icomplete is not being told under which conditions this is true and it's
not being told *how* it could be recomputed (e.g. by looking for
candidates matching "foob" or by looking for candidates matching
"f.*o.*o.*b", ...).

So in order to be able to avoid recomputing the candidates "from
scratch", we'd need the rest of the completion code to give us more
info, but there is no such infrastructure.

What the current completion system expects instead is that if the time
needed to recompute the candidates can be large, the *completion table*
should use a cache.


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 29833 <at> debbugs.gnu.org, Shuguang Sun <shuguang <at> gmail.com>
Subject: Re: bug#29833: icomplete re-build the completion table after each
 key press
Date: Fri, 23 Jul 2021 14:51:22 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> So in order to be able to avoid recomputing the candidates "from
> scratch", we'd need the rest of the completion code to give us more
> info, but there is no such infrastructure.
>
> What the current completion system expects instead is that if the time
> needed to recompute the candidates can be large, the *completion table*
> should use a cache.

The completion code has gotten a lot of work lately, but I guess the
conclusion here is that there's nothing specific to do in this bug
report, so I'm closing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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