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

Previous Next

Full log

Message #11 received at 11906 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 11906 <at> debbugs.gnu.org
Subject: Re: bug#11906: 24.1; completion-at-point failures
Date: Fri, 10 May 2013 14:38:09 +0800

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

Previous Next

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