bug#29833: icomplete re-build the completion table after each key press

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

> The icomplete re-build the completion table
> 'completion-all-sorted-completions' after each key press.

This is considered normal.
The reason is that icomplete can't know in general how to take the
list of matching completions for "foob" or for "fo" (or for any other
string for that matter) and compute the corresponding list of
matching completions.

This is because it depends on lots of details.  E.g. when completing
files when going from "foo" to "foo/" the list of completions is
completely changed.  In other cases, "foo" matches something using
a particular completion-style but "foob" doesn't, so a different
completion-style will be used, ...

It is true that in many case the completions of "foob" are a subset of
the completions of "foo", so we could recompute them faster but
icomplete is not being told under which conditions this is true and it's
not being told *how* it could be recomputed (e.g. by looking for
candidates matching "foob" or by looking for candidates matching
"f.*o.*o.*b", ...).

So in order to be able to avoid recomputing the candidates "from
scratch", we'd need the rest of the completion code to give us more
info, but there is no such infrastructure.

What the current completion system expects instead is that if the time
needed to recompute the candidates can be large, the *completion table*
should use a cache.


        Stefan