all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.