[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: Mon, 12 Apr 2021 03:32:14 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

On 11.04.2021 16:08, Daniel Mendler wrote:

Yes, I think we are mostly on the same page. If you look at my Consult async pipelines there are functions which do debouncing/waiting etc.

1. sink      ^
2. wait      | candidates, refresh, flush requests etc
3. debounce  |
4. source    |

The incoming candidates are sent from the source (a process or web query source) to the sink and then the sink also performs the refreshing by talking directly to the UI. Then the UI can also make its own decisions what to do with the refreshing requests.

Sounds good.

Sounds like you have what is needed to propose an "async" extension to the standard completion tables API?

Yes, one could consider it as that. But maybe it it is sufficient to only provide a general refresh hook which I proposed initially. This way the core API would stay simple and everything could be implemented on top without constraining everything directly.

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?

reply via email to

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