From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16251-done@debbugs.gnu.org
Subject: bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
Date: Fri, 27 Dec 2013 16:55:11 -0800 (PST) [thread overview]
Message-ID: <818df3a7-a5fa-4871-86e1-0bd5d8e4a5fc@default> (raw)
In-Reply-To: <jwv4n5uv4fz.fsf-monnier+emacsbugs@gnu.org>
> > 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.
next prev parent reply other threads:[~2013-12-28 0:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-25 5:58 bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now Drew Adams
2013-12-25 6:18 ` Jambunathan K
2013-12-25 17:17 ` Drew Adams
2013-12-25 8:30 ` Daniel Colascione
2013-12-25 17:23 ` Drew Adams
2013-12-25 18:02 ` Eli Zaretskii
2013-12-27 12:59 ` Stefan Monnier
2013-12-28 0:55 ` Drew Adams [this message]
2013-12-28 8:51 ` Eli Zaretskii
[not found] <<497ebd3d-d69b-4ac4-9d8c-ca2f4a1a2ac1@default>
[not found] ` <<jwv4n5uv4fz.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <<818df3a7-a5fa-4871-86e1-0bd5d8e4a5fc@default>
[not found] ` <<83y5352wae.fsf@gnu.org>
2013-12-28 16:01 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=818df3a7-a5fa-4871-86e1-0bd5d8e4a5fc@default \
--to=drew.adams@oracle.com \
--cc=16251-done@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).