[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: Sun, 11 Apr 2021 15:08:19 +0200

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.


reply via email to

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