bug#11906: 24.1; completion-at-point failures

[Stefan Monnier]

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