Spencer Baugh <sbaugh@janestreet.com> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think we should try and fill the buffer lazily.  We don't have much
>> experience with "jit" populating a buffer (the closest I can think of is
>> the `vlf` package, which doesn't do "jit", IIRC), so it may take some
>> trial-and-error until we have something that works, but it
>> seems worthwhile.
>
> Yes, I think filling the *Completions* buffer lazily would be way better
> than limiting the size of the buffer, thanks everyone for your comments.
>
> I think it would be sufficient to do something simple, and just split
> filling the *Completions* buffer into two parts:
>
> - In minibuffer-completion-help, insert only enough completion
> candidates that the part of the *Completions* buffer that's displayed in
> a window initially looks normal.  Save the rest of the completions in a
> buffer-local in *Completions*.
>
> - Upon any kind of interaction with the *Completions* buffer, insert all
> the rest of the completion candidates in completions--finish-populate.
>
> We could be lazier than this, but this is probably sufficient to give a
> big speedup, since I think *Completions* is rendered much more often
> than it's interacted with.
>
> So to do this, all we need is a way to do completions--finish-populate
> at the right time.
>
> I'm not sure when to do that.  Maybe we could just call it in
> window-selection-change-functions and with-minibuffer-completions-window
> and maybe a few other places?

I've done this in the attached patch and it seems to work well.  As a
fallback, there's also a button at the end of the *Completions* buffer
to finish filling it, in case something goes wrong with the automatic
laziness.

Incidentally, filling the buffer lazily allows the default completion
frontend to start using completion-lazy-hilit, which will be another
nice performance benefit (which can happen in a later follow-up patch).