GNU bug report logs - #11906
24.1; completion-at-point failures

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 11906 <at> debbugs.gnu.org
Subject: bug#11906: 24.1; completion-at-point failures
Date: Fri, 10 May 2013 16:36:05 -0400

>>> completion-at-point also invokes those functions in order to decide when
>>> to exit. This causes problems illustrated at the beginning of this
>>> report and, for example, I have also experienced delay in inserting
>>> space, dot, etc following a completion.
>> Can you explain how "this causes problems"?  What makes you think
>> it's related?
> OK, I just hit another performance issue with this repetitive invoking
> of completion functions by completion-at-point. To see this issue:

> 1. emacs -q (choose an emacs that doesn't have the fix in revision 112539)
> 2. M-x run-octave
> 3. Type 'uint <TAB>'
> 4. Type 'history 10'

I don't understand this recipe: where should I type "history 10"?  right
there after the "uint" text?

> You should see:

>  1040 completion_matches ("uint");

>  1041 completion_matches ("uint");

>  1042 completion_matches ("uint");

>  1043 history 5

Where should I see it?

<fiddling around some more>

Ah, OK.
so I should type RET before "history 10", so history shows me the last
commands run by octave.

> So basically computation for the matches against 'uint' has been done
> three times.

Fine, yes.  There can be various reasons why the completion table is run
several times.  In the present case, 2 is the minimum: once to try and
complete "uint" (which just returns "uint") and once to get the
completion candidates.  Why there's a third call?  I couldn't tell you
off the top of my head.  Maybe it's an inefficiency somewhere.

> Now when the computation is expensive (such as against the
> empty string "") one should observe a terrible delay.

The difference between 2 and 3 calls shouldn't be sufficiently large to
go from "acceptable" to "terrible delay".

> I have to work around this issue in octave by revision 112539.

Using a cache is a good idea: when there's no completion, the completion
code may call the completion-table many more times than just 3 times
(typically, it will call it at least once per completion-style).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.