Re: Updating *Completions* as you type

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 13 Oct 2023 14:01:38 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: sbaugh@catern.com
> >> Date: Thu, 12 Oct 2023 19:53:53 -0400
> >> 
> >> 
> >> It would be nice if there was a built-in customization which caused
> >> *Completions* to update as you type, as long as that buffer is visible.
> >> I imagine such a request has been made before, so what is the obstacle
> >> to adding it?
> >
> > I think we have alternative completion schemes, like ido.el and
> > others, which update the list of the completion candidates as you
> > type, albeit not in the *Completions* buffer.  Why would we need yet
> > another knob in the default completion scheme?
> 
> ido-mode only works for files and buffers, not all minibuffer
> completion, and is also unmaintained and sometimes buggy besides that.
> 
> icomplete-mode (and its derivatives) doesn't work for in-buffer
> completion.

What do you mean by "in-buffer completion"?

> Also, it is buggier than the default completion scheme.

Then let's fix those bugs before we consider adding yet another
completion scheme (with its own bugs).

Does anyone else here thinks we need yet in core another completion
feature in addition to what we have already (which, btw, includes
fido-mode as well)?

> >> (Btw, if we had this behavior, it also seems like it would help with
> >> another long-time request: asynchronous completion support.  A
> >> programmed completion table could internally do something asynchronous
> >> and stateful, and accumulate results over time, and return more and more
> >> results each time Emacs calls all-completions/try-completion.  If Emacs
> >> automatically called all-completions with such a programmed completion
> >> table, the resulting behavior would be an acceptable approximation of
> >> asynchronous completion, without having to complicate the programmed
> >> completion API.)
> >
> > IIUC what you mean by "asynchronous completion", it is a terrible
> > idea.  How can anyone type text without getting immediate feedback for
> > what he/she typed?  When I sometimes see this (due to network delays
> > or system load or whatever), it is a terrible UX.
> 
> By asynchronous completion, I just mean being able to type, and trigger
> completion, and have completions appear incrementally as they are
> computed, without interfering with you continuing to type.  I don't
> think that stops immediate feedback for typing.

If it's asynchronous, then how can we make sure the feedback is
immediate?