bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29833: icomplete re-build the completion table after each key press


From: Shuguang Sun
Subject: bug#29833: icomplete re-build the completion table after each key press
Date: Sat, 6 Jan 2018 15:27:27 +0800

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@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

Attachment: minibuffer.el.patch
Description: Binary data

Attachment: icomplete.el.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]