GNU bug report logs - #11906
24.1; completion-at-point failures

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Leo Liu <sdl.web <at> gmail.com>, 11906 <at> debbugs.gnu.org
Subject: bug#11906: 24.1; completion-at-point failures
Date: Wed, 22 May 2013 15:16:01 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.