bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now

[Daniel Colascione]

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.