Usage of :history in consult--read?

[armindarvish]

As part of my experiments in consult-web, I have been trying to get async sources to sort candidates (meaning they remember my previous selectios with orderless), however whenever I set the :history to '(:input hist-var) to get the search query in the history as opposed to the selected candidate. sorting stops working. Here is a demo of it with @karthink's consult-web-mini prototype:

@minad Is there some limit in underlying completing-read causing this or is there a work around for this?

[minad]

Yes, this is a limitation. The history either stores the candidates or it stores the input. It is a single history variable after all. If we store the candidates itself, we can sort by recency. If we store the input, we lose this information.

The reason why I've accepted this limitation so far is that the async commands, which store the input, also produce results in their own specific order. This means that I want to disable sorting in the UI, also because I don't want the UI to dynamically reorder the candidates, when they come in asynchronously. Furthermore, the async commands can quickly produce 100k candidates, and at that point, UI sorting may become a bottleneck.

[armindarvish]

@minad I see.

The reason why I've accepted this limitation so far is that the async commands, which store the input, also produce results in their own specific order. This means that I want to disable sorting in the UI, also because I don't want the UI to dynamically reorder the candidates, when they come in asynchronously. Furthermore, the async commands can quickly produce 100k candidates, and at that point, UI sorting may become a bottleneck.

This does make sense. There are cases where I think it is useful to turn the sorting on and I was hoping I could let the user decide whether they want the dynamic sorting or not. For example in my omni search, it would be nice to allow orderless to show me the candidate I picked before on the top. But if this is a limitation in completing--read and cannot easily be addressed, then we can accept the limitation for the reasons you mentioned.

One question would be, if there is an elegant way to separate the two histories in general? or somehow keep both information in the same hist-var (even if we don't use it for sorting). For example, if I keep the previous selections in a separate hist-var, I an still use it for narrow down after a dynamic search is done and sorted. I am currently adding the selection to a separate hist-var manually, just to have both information (the search query and the selected candidate) but there might be better ways I have not thought of and have not figured out what would be an intuitive way to then use the selection history for narrow downs.

[minad]

The vertico-repeat package maintains a separate input history - but for all commands. Maybe this can be useful. Another option would be to use a separate variable (as you did) or adding text properties to the candidates. You could also add a property to the history variable, keeping track of input separately. The problem in all scenarios is that you need separate commands to access the two different histories.

[minad]

For some "history" - a while back I experimented with more extensive history support, maintaining both input and candidate history. See my Uchronia prototype. However it turned out that the functionality wasn't requested often or needed at all, also given the considerations mentioned in #1014 (comment). So that's also the reason why we are where we are and why I haven't put more effort into this. I recycled some features for vertico-repeat, but that's it.