[Top][All Lists]

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

Re: Improvement proposals for `completing-read'

From: Daniel Mendler
Subject: Re: Improvement proposals for `completing-read'
Date: Mon, 12 Apr 2021 02:40:30 +0200

On 4/12/21 2:32 AM, Dmitry Gutov wrote:
I'm not sure if that would work for code completion. Aside from tracking which value belongs to which frontend, and the associated bugs with hooks you mentioned, how to you invalidate the results?

For instance, there is a request, it has been made a while ago, and the context has changed (the buffer has changed, position has changed, etc). The request has taken a long time but finally the response has arrived. How do you reliably ignore it? Or, ideally, are able abort it (if it's a one-time external process, perhaps killing the search process)?

If the result is some kind of "future" value, the handler code can either change some variable in the lexical scope once its execution reaches the point of "we don't need that computation anymore", or could even call some generic method like future-abort.

How does the general refresh hook solve these problems?

I don't know how it looks in the context of code completion. But in the context of the minibuffer completion, the state is minibuffer-local. The hook is executed within the minibuffer, which belongs to the async operation. With Consult async you can have multiple recursive minibuffers where each performs an async operation. Does this answer your question?


reply via email to

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