GNU bug report logs -
#16251
24.3.50; `icomplete-mode' breaks my file opening now
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Wed, 25 Dec 2013 05:59:02 UTC
Severity: normal
Found in version 24.3.50
Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 16251 <at> debbugs.gnu.org (full text, mbox):
On 12/24/2013 09:58 PM, Drew Adams wrote:
> [The build noted below is the one this bug report is for. But I'm
> sending this using an older build than the one noted below, because of
> another new bug, which prevents using `report-emacs-bug']
>
>
> Just a preliminary heads up for now. Hope to add more info later, when
> I get some time.
>
> I downloaded this build, and when `icomplete-mode' is on, with my setup
> it takes several seconds to gather the list of file candidates in my
> usual directory. With a build from two days ago, this does not happen.
> And if I turn off icomplete mode it also does not happen.
>
> It seems that something was changed in the icomplete mode code recently
> that breaks at least my file-finding code.
>
> With emacs -Q I do not notice the problem (well, maybe a slight delay).
> I see that C-x C-f now shows completions immediately, without my typing
> any prefix. That is not true in the build from 2 days ago.
Mea culpa: I committed a change that caused icomplete to try to show
completions right away by default. As Jambunathan mentions, setting
icomplete-show-matches-on-no-input to nil should restore the old
behavior. The old behavior isn't optimal, though, and icomplete isn't a
replacement for iswitchb without the feature I added.
Maybe we can change icomplete-show-matches-on-no-input to a command list
--- this way, we could show completions early for buffer switching, but
not for finding files.
Why is finding the list of files so slow for you? Don't you experience
the same performance problem after typing a character and forcing
completions to show up? We call the completion function inside
while-no-input, so we should abort the "several seconds" of work as soon
as you start typing.
This bug report was last modified 11 years and 208 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.