[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
From: |
Drew Adams |
Subject: |
bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now |
Date: |
Fri, 27 Dec 2013 16:55:11 -0800 (PST) |
> > 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.
<embarrassment>
This was my bad. I was passing this to `cl-delete-if':
(regexp-opt completion-ignored-extensions). Taking that calculation
out of the loop saved 13 seconds! (99% of the total time).
</embarrassment>
FWIW, here are some times (now) of various parts (with my code, with
my find-file replacement, in my typical startup directory, about 2400
files):
completion-all-completions: 680 ms
deleting duplicates: 70 ms
sorting: 470 ms
Of course, sorting depends on the sort predicate. This was with a
directories-first-then-alphabetical sort.
> I just reverted icomplete-show-matches-on-no-input to nil, which
> I think is the right default.
Thx.
> That it can take a long time to get the completions is not in itself
> a bug. There are 2 potential bugs left, tho:
>
> - hitting a key should interrupt the completions processing (so that
> the long wait should not prevent you from getting work done).
> If it doesn't, then we have a bug. Please report it separately, with
> as much details as possible to reproduce it (it's probably a problem
> in the C code).
That seems to work OK (as before).
> - ideally completion should never take that long, so we probably have
> a performance bug somewhere. Of course, that might also be in your
> local code (.emacs, icicles, ...).
See <embarrassment>, above.
A problem I do notice now (not sure why now) is that sometimes keys
that I hit are "lost" instead of appearing in the input. AFAICT, this
happens only when Icomplete is on. It can make completing input
painful, to say the least. I don't have a handle yet on just what
the behavior is or what causes it. Just mentioning it now in case
someone happens to notice it also for vanilla Emacs.
---
FWIW - One other thing is somewhat unfortunate in my context, so far:
When you cycle among completion candidates (Icicles cycling, not
Icomplete cycling), or when there is a sole matching candidate, by
default Icicles shows info about the current (or the sole) candidate
in the (*Completions*) mode line, for N sec. Hitting a key interrupts
this, of course - it is done using `sit-for'.
But of course `post-command-hook' actions do not take place until
that delay is over. This means that icompletions do not show up
until the mode-line display is finished. I guess I should instead
show the info until some timer gets rid of it, so that it stays
visible even when `post-command-hook' is run.