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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Because the first call is for try-completion (i.e. "give me the
completion") and the second is for all-completions (i.e. "give me all
matching candidates"), so the info returned by the first call is not
sufficient to avoid the second call.

As you've seen there can be a second call (to try-completion with the
result of the first call to try-completion) to check if the completion
is unique.  Plus another call (to test-completion) to check if the
result of the first try-completion was complete.

> So, suppose we do provide a caching function. Would it cache more than
> just one pair?

Probably, yes.  It would turn test-completion and try-completion into
calls to all-completions and then cache one "arg+result" of
all-completions (this pair would be sufficient to cover all calls to
test/try/all-completion for any argument string which has `arg' as its
prefix).

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

Right, that's the idea.


        Stefan