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 23:40:39 -0400

>> The difference between 2 and 3 calls shouldn't be sufficiently large to
>> go from "acceptable" to "terrible delay".
> It is a difference between 1 and 3 calls because a user can also run
> octave in terminal and find that how responsive it actually is.

But the generic completion code can't easily go down to a single call in
the general case.

> I think if completion-at-point can work well when there is a 2-second
> cost in a completion-at-point function, it can provide an excellent
> experience.

Obviously it can, via caching.  Most completion tables which incur
a significant computation code should use caching, but we can't use
caching unconditionally, because it's hard to come up with a general
conditions under which the cache can be reused or needs to be flushed.

As mentioned, we could try and provide a generic completion-table cache
so as to make it easier to write completion tables that have
a significant computation cost.  Patches welcome.


        Stefan

Previous Next

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