[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Daimrod
Subject: bug#11906: 24.1; completion-at-point failures
Date: Sun, 12 May 2013 01:11:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <address@hidden> 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.


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


Attachment: pgpIJP6K6cEZ5.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]