Re: Updating *Completions* as you type

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Sun, 15 Oct 2023 11:55:47 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: sbaugh@catern.com
> >> Date: Sat, 14 Oct 2023 16:05:11 -0400
> >> 
> >> Yes, agreed.  Taking inspiration from zcomplete, I wrote this patch to
> >> provide just this feature, thoughts?
> >
> > I tried this.  The update is slow (most probably because it works off
> > the post-command-hook), and the UX is therefore extremely unpleasant
> > if you type fast enough.
> 
> Interesting.  Can you say more about what completion you're doing for
> which the update is slow?

I started by typing "C-x C-f TAB".

> I would have expected the while-no-input to cause the update to not
> block you if you type fast.

while-no-input lets me type, but does nothing to speed up the updates
of the *Completions* buffer; quite the contrary: it leaves it
outdated.

> >> +    (while-no-input
> >> +      (let ((non-essential t))
> >                 ^^^^^^^^^^^^^^^
> > Why?
> 
> This I borrowed from zcomplete.  It seems sensible, since
> non-essential's docstring says:
> 
>   E.g., it can be used to prevent Tramp from prompting the user for a
>   password when we are [...] displaying possible completions before the
>   user even asked for it.

So completion on remote files will not be able to benefit from this?

> >> +        (when (and (get-buffer-window "*Completions*" 0)
> >> +                   (not (memq this-command 
> >> completions-no-auto-update-commands)))
> >> +          (redisplay)
> >              ^^^^^^^^^^^
> > Why do you need this?
> 
> post-command-hook's docstring says:
> 
>   It is a bad idea to use this hook for expensive processing.  If
>   unavoidable, wrap your code in ‘(while-no-input (redisplay) CODE)’ to
>   avoid making Emacs unresponsive while the user types.

Did you try this without the 'redisplay' call?