Re: Improvement proposals for `completing-read'

[Daniel Mendler <mail@daniel-mendler.de>]

On 4/11/21 2:51 AM, Dmitry Gutov wrote:>>> I would probably say that a 
UI should itself know better when to
>>> refresh or not, but I'm guessing you have good counter-examples.
>>
>> One could update the UI using some timer if an async source is used 
>> (polling). However since I am setting this on top of the 
>> `completing-read' infrastructure I felt it to be better to do it the 
>> other way round, since the table is only queried when the user enters 
>> new input. I guess for fast sources polling will be as good, but for 
>> slow sources, notifying the UI is better.
> 
> Perhaps we're just talking about the same thing, differently.
> 
> What I meant, the source should invoke the callback when it gets new 
> data, and the callback should store the result somewhere, and it can 
> notify the UI about the possibility of refreshing (the frontend 
> implements the callback, so it knows whether and how to do it). But 
> whether to refresh right away, or wait, debounce, or simply discard the 
> output, should be the frontend's choice.

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 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.

Daniel