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

[Daimrod]

Stefan Monnier <monnier@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

pgpHGACTXIdHL.pgp
Description: PGP signature