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

[Leo Liu]

On 2012-07-12 22:00 +0800, Stefan Monnier wrote:
>> Emacs.  It seems completion-at-point should be able to do its entire work
>> after obtaining once the data from those functions. This would free
>> users of completion-at-point-functions from worrying about caching.
>
> Sometimes, you can't get the whole data at once (e.g. completion of
> a file-name would have to return all the files in all directories if it
> had to be done "a once").
>
> So, this is not an option.  But we could provide a standard
> completion-table constructor that provides caching.
>
>> 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'

You should see:

 1040 completion_matches ("uint");

 1041 completion_matches ("uint");

 1042 completion_matches ("uint");

 1043 history 5

So basically computation for the matches against 'uint' has been done
three times. Now when the computation is expensive (such as against the
empty string "") one should observe a terrible delay.

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

Leo