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