Re: Updating *Completions* as you type

[Daniel Semyonov <daniel@dsemy.com>]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

My package Vcomplete implements this functionality, however I stopped developing it since I reached the conclusion that this isn’t a very useful feature (to me) and all other features of the package were implemented in some form in Emacs.  It still works though, and will use the base Emacs implementation for those other features if they’re available.

Some notes:
- Using after-change-functions to implement this can cause weird issues in packages like Tramp and embark which modify the minibuffer during completion.
- If there are a lot of completions, the completions buffer can take a while to update, and you need to make sure this process blocks user input as little as possible.
- I recall having issues with the completion buffer popping up randomly when typing after completing in a buffer, but I don’t remember why it happened and how I solved it.
- There is also the package aggressive-completion which does something similar.

Daniel

(Sent from a phone, sorry for any weird formatting)

> On 13 Oct 2023, at 8:31, sbaugh@catern.com wrote:
> 
> 
> 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 would like to figure out a solution which everyone is happy with, and
> then I would be happy to implement it.  It seems to me that it's just a
> matter of, after each keystroke, triggering (for minibuffer completion)
> minibuffer-completion-help or (for buffer completion) some new function
> to populate *Completions* with all-completions output.  This could (I
> guess) be done with after-change-functions, although maybe others have a
> better idea.
> 
> (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.)
> 
> 

[-- Attachment #2: Type: text/html, Size: 3419 bytes --]