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

Previous Next

Full log

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

From: Daimrod <daimrod <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Leo Liu <sdl.web <at> gmail.com>, 11906 <at> debbugs.gnu.org
Subject: Re: bug#11906: 24.1; completion-at-point failures
Date: Sun, 12 May 2013 01:11:48 +0200

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

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

Hello,

Maybe I didn't understand what you mean, but AFAIK it's already
available. You can compute a list of possible completions only once and
then return a completion table (start end COLLECTION) where collection
is a function described here (info "(elisp) Programmed Completion").

-- 
Daimrod/Greg

[Message part 2 (application/pgp-signature, inline)]

Previous Next

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