Re: Improvement proposals for `completing-read'

[Dmitry Gutov <dgutov@yandex.ru>]

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?