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

[Dmitry Gutov <dgutov@yandex.ru>]

I've seen this very same problem when writing and using a
completion-at-point function for Ruby, via external live process, so
it's also comparably slow.

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.

Why not?

I have a function, called `robe-complete-thing', which is used as a
"dynamic completion table" via `completion-table-dynamic'.

Whenever I press `C-M-i' in a relevant buffer, `robe-complete-thing'
gets called 2 times if the symbol is "complete, but not unique", or 3
times if the symbol is not complete, and the *Completions* buffer should
be displayed.

Whatever code drives this logic, I imagine all places that access the
dynamic completion table do that is specific order. And since they all
look up completions for the same term, can't the first of them save the
lookup result, so that all other places will use the saved value? All
that in the scope of one `complete-symbol' call.

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

The one most visible problem case is when the dynamic completion table
is called several times at once for the same term.

Caching is a possible solution, but it doesn't seem to me that caching
anything more than the last request-response pair would be too useful.

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

So, suppose we do provide a caching function. Would it cache more than
just one pair? If not, it won't be too hard to do in
`completion-table-dynamic', or in an additional function that would wrap
FUN and then pass it to `completion-table-dynamic'.