Progressive input

[alecmev]

Thanks for making fzf, great UX! This is a feature request, so I'm skipping the template.

I'm using fzf like so:

fd --follow --hidden --no-ignore | proximity-sort . | fzf --tiebreak=index

Works fine, but proximity-sort needs all of the input to process it, so in ~, for example, it ultimately takes a few seconds for anything to appear, which is suboptimal.

Solution A is to have fzf display a "lower-quality" list of paths of my choosing while it's waiting for proximity-sort to produce the first line.

Solution B is to have proximity-sort pipe through the lines coming from fd to fzf as they come, do the necessary processing, somehow signal fzf to start over (and possibly change its tie-breaking mode), and pipe out the sorted data.

In both solutions fzf must wait for the line matching the currently-selected one to be piped in before updating the list, as to avoid jarring jumps. If there's no such line then gotta wait for the end of the input.

Would you be interested in either of these? Or is it already possible, maybe? Comments? 🙂

[rayiik]

Bash zsh fish? There may exist a solution but it’s hard to tell with out more info the fzf —sync (for multi stage filtering) flag comes to mind also if Your using it to find directories or files you can
fd —type (path|file|link) will speed up your results also considere the —exec or —exec-batch proximity-sort (don’t know that command so you’ll have to figure out if those are appropriate) also fzf —sort=length will match closest to the beginning of the line index is automatically appended to the end of whatever sort criteria you use I believe

[alecmev]

Thanks for the suggestions!

To simplify the use case, you can think of proximity-sort as a regular sort. It needs the whole input to process it properly. If proximity-sort were a part of fzf then this would be a non-issue, the sorting would be continuously updated as fd pumps in the data, but this isn't possible with separate tools.

I have since concluded that the best option might be to have fd itself do the sorting, given that fzf doesn't want it.

[rayiik]

ok so two that i have tested out that work so far -uu = hidden/noignore

fd --follow -uu | fzf --tiebreak=index --preview='cat {+f} | proximity-sort .'
fd --follow  -uu | fzf --tiebreak=index --bind='f9:toggle-all+reload:fd -uu --follow | proximity-sort .' --no-clear

first one will display your sorted selection in the preview window second one toggles all and sorts from the off tmp file you could remove the toggle all put it on a different binding then manually filter and select/remove the files you want before the reload as its being read from file and not genereated should be much faster + you can start filtering then by the time youve narrowed it down a bit it should be fully loaded

[alecmev]

Thanks again!

Hmm, I wasn't able to get either of the suggested workarounds to work (the first one previews only one line, and the second one never updates after pressing F9), but even if I could, I feel like the UX is just not there. The preview would take as long to appear as in the case outlined in the original post, so the utility of it is quite limited, and having to refresh the list manually with a binding is something that a computer should be able to do for me 🙂

[rayiik]

I think part of the issue is the scope of the search where are you running in from? because with your test case if I ran it from my root we are talking over 3 million files so far and counting. if you throw in a couple of filters (fd --type file/directory/link/socket/ --depth nor broke it down into fields indexing them for future use and then ran them in parallel and fed them to fzf I'm just not sure what your searching for but would definitely help to know what your intended target is that your searching for because if you can bring the total files searched down there's a couple of possible workarounds that might work such as running in stages or setting updated variables through array's and heredocs but as it stands right now I just know your searching for everything everywhere and that you want to do it with realtime updates and you want whats closes to you physically first (that being said fd --depth {1..4}) limits your recursive search to 4 folders higher or lower and since your using --follow if your only looking to path out links you can --type=link on fd) but if your just trying to recursivly scan your entire filesystem your not going to get it done the way your hoping (might want to check out filelight light if thats your goal) but theres not much i can do with-out knowing what your hoping to achieve.

[junegunn]

A simpler solution would be to use a directory traversal program that performs breadth-first search. Unfortunately, fd doesn't seem to support the option. sharkdp/fd#28

[wind0204]

Just in case anyone is looking for a low-hanging fruit of breadth-first traversal I share what I have done with my Alt+C : #4523 (comment)
Hint: bfs