unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
@ 2013-12-25  5:58 Drew Adams
  2013-12-25  6:18 ` Jambunathan K
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Drew Adams @ 2013-12-25  5:58 UTC (permalink / raw)
  To: 16251

[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.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-24 on ODIEONE
Bzr revision: 115738 cyd@gnu.org-20131225030511-ru56hhc243pxja04
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  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-27 12:59 ` Stefan Monnier
  2 siblings, 1 reply; 10+ messages in thread
From: Jambunathan K @ 2013-12-25  6:18 UTC (permalink / raw)
  To: Drew Adams; +Cc: 16251

Drew Adams <drew.adams@oracle.com> writes:

> It seems that something was changed in the icomplete mode code recently
> that breaks at least my file-finding code.

What happens if you turn this off:

    icomplete-show-matches-on-no-input





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  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  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
  2 siblings, 2 replies; 10+ messages in thread
From: Daniel Colascione @ 2013-12-25  8:30 UTC (permalink / raw)
  To: Drew Adams, 16251

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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  2013-12-25  6:18 ` Jambunathan K
@ 2013-12-25 17:17   ` Drew Adams
  0 siblings, 0 replies; 10+ messages in thread
From: Drew Adams @ 2013-12-25 17:17 UTC (permalink / raw)
  To: Jambunathan K; +Cc: 16251

> > It seems that something was changed in the icomplete mode code recently
> > that breaks at least my file-finding code.
> 
> What happens if you turn this off: icomplete-show-matches-on-no-input

Yes, thank you!  That removes the problem.

Any idea (without knowing my code) why this makes a huge difference
with my code but not a huge difference with emacs -Q?  IOW, is there
something particular in the new icomplete code to be aware of here?





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  2013-12-25  8:30 ` Daniel Colascione
@ 2013-12-25 17:23   ` Drew Adams
  2013-12-25 18:02   ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: Drew Adams @ 2013-12-25 17:23 UTC (permalink / raw)
  To: Daniel Colascione, 16251

> Why is finding the list of files so slow for you?

I don't know.  And I don't have time right now to track it down.
But I'll try to take a look later some time.

> Don't you experience the same performance problem after typing
> a character and forcing completions to show up?

No, absolutely not.

> We call the completion function inside while-no-input, so we
> should abort the "several seconds" of work as soon as you start
> typing.

I didn't start typing.  In Icicles it often makes sense to show
all initial completions from the outset, either automatically or
on demand.

While waiting for better understanding of the problem, and
possibly a fix if there is in fact a bug and solution, I will
automatically turn off `icomplete-show-matches-on-no-input'
when Icicle mode is turned on.

BTW, there is no such problem with using IswitchB with Icicles,
AFAIK.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  2013-12-25  8:30 ` Daniel Colascione
  2013-12-25 17:23   ` Drew Adams
@ 2013-12-25 18:02   ` Eli Zaretskii
  1 sibling, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2013-12-25 18:02 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: 16251

> Date: Wed, 25 Dec 2013 00:30:07 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 
> 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.

Maybe because input on Windows is not signal-driven, and therefore
while-no-input relies on the Lisp code paying frequent attention to
QUIT.

I tried just now enabling icomplete-mode in "emacs -Q", and can
confirm that "C-x C-f" becomes painfully slow to react to typing in a
large directory, especially with a cold cache.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  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  8:30 ` Daniel Colascione
@ 2013-12-27 12:59 ` Stefan Monnier
  2013-12-28  0:55   ` Drew Adams
  2 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2013-12-27 12:59 UTC (permalink / raw)
  To: Drew Adams; +Cc: 16251-done

> 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.

I just reverted icomplete-show-matches-on-no-input to nil, which I think
is the right default.  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).
- 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, ...).


-- Stefan





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  2013-12-27 12:59 ` Stefan Monnier
@ 2013-12-28  0:55   ` Drew Adams
  2013-12-28  8:51     ` Eli Zaretskii
  0 siblings, 1 reply; 10+ messages in thread
From: Drew Adams @ 2013-12-28  0:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 16251-done

> > 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.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
  2013-12-28  0:55   ` Drew Adams
@ 2013-12-28  8:51     ` Eli Zaretskii
  0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2013-12-28  8:51 UTC (permalink / raw)
  To: Drew Adams; +Cc: 16251

> Date: Fri, 27 Dec 2013 16:55:11 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16251-done@debbugs.gnu.org
> 
>  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.

How much time does sorting take if you request just alphabetical,
without directories-first?  It should take zero on Windows; if it
doesn't, our sorting algorithm should be improved.





^ permalink raw reply	[flat|nested] 10+ messages in thread

* bug#16251: 24.3.50; `icomplete-mode' breaks my file opening now
       [not found]     ` <<83y5352wae.fsf@gnu.org>
@ 2013-12-28 16:01       ` Drew Adams
  0 siblings, 0 replies; 10+ messages in thread
From: Drew Adams @ 2013-12-28 16:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 16251

> >  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.
> 
> How much time does sorting take if you request just alphabetical,
> without directories-first?  It should take zero on Windows; if it
> doesn't, our sorting algorithm should be improved.

I no longer have the debugging set up for this (calls to `message'
etc., since it is impossible to use the debugger with Icomplete).  

But IIRC it was not very different from that.  But this the sorting
I use here is the Icicles sorting, so the efficiency of its
implementation should be irrelevant to emacs -Q.  That is, if
Icicle mode is on, I use the current Icicles sort function.





^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2013-12-28 16:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

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).