[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improvement proposals for `completing-read'

From: Dmitry Gutov
Subject: Re: Improvement proposals for `completing-read'
Date: Wed, 14 Apr 2021 03:00:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]