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

[Stefan Monnier]

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