Re: Improvement proposals for `completing-read'

[Dmitry Gutov]

On 12.04.2021 14:04, Daniel Mendler wrote:
> On 4/12/21 12:47 PM, Dmitry Gutov wrote:
> > What happens if you have an anomalously long running request in one 
> > nested minibuffer, which you exit, so it arrives in the "parent" one 
> > that's still managed by Consult, but shows the results for a different 
> > command/input/etc?
>
> This cannot happen. If you exit the minibuffer, the running request will 
> be terminated.

Because the process belongs to the buffer?

> The parent minibuffer, maybe also running a Consult 
> command (or something else) is isolated from the child minibuffer and no 
> disruption should happen.
>
> I just tested running nested `consult-ripgrep` and that should work, but 
> for some reason there is a problem 
> (https://github.com/minad/consult/issues/272). I have to check if this 
> can be fixed. So what I described to you is how everything should work 
> in theory, since the state is captured in the closures.
>
> The `consult--async-sink` contains this code which performs the refreshing:
>
>       ;; Refresh the UI when the current minibuffer window belongs
>       ;; to the current asynchronous completion session.
>       (when-let (win (active-minibuffer-window))
>         (when (eq (window-buffer win) buffer)
>           (with-selected-window win
>             (run-hooks 'consult--completion-refresh-hook)))))

OK, so it seems like the sink saves the "context" which it was called 
from, and then compares it against the current one upon completion, and 
does nothing when they don't match.

Sounds good for minibuffers, but not so great for code completion, where 
context is more complex. And since completing-read shares the notion of 
completion table with completion-at-point-functions, I think any async 
support we add should work for both purposes.