iterfzf
iterfzf copied to clipboard
Is there a way to sort the results by match?
First off, thank you so much for this package - it's soooo useful!
That being said, is there a way to sort the results by how well they match? When I'm searching for large file paths, it's kinda annoying that irrelevant queries pop up first just by random chance.
For example, given the query 'abc', and file paths
/files/And/Butterflies/and/Cookies /abc /things/And/stuff/But/Crackers
it's annoying that /abc, the obvious best match, isn't on the far top or the far bottom. Is there a way to remedy this? Sorting is pretty fast in python, so I wouldn't mind waiting for it to re-sort the entire list every time the screen updates if nessecary
Thank you, Ryan
(Also, since it's not 100% clear what makes one match better than another, perhaps there's a way to pass it a custom sorting function somehow - so that I could tailor it to my use cases?)
(Also, since it's not 100% clear what makes one match better than another, perhaps there's a way to pass it a custom sorting function somehow - so that I could tailor it to my use cases?)
Hi Ryan! If I understood this question correctly, you should try putting a ' before you type in the prompt. Alternatively, have you tried passing the -e|--exact flag with iterfzf(exact=True)? It won't necessarily sort then better, but it does make the filtering a little bit cleaner as it removes the fuzzy finding. If these don't work, I can look making into a patch for you.
@SqrtRyan I've made a pull request #23 which should fix this issue. I was using iterfzf and noticed the poor matching (as compared to raw CLI fzf) and discovered it is because of a flag passed to the executable on every run. Disabling this flag seems to put higher quality matches at the top.
@SqrtRyan, @gikeymarcia
- One can sort their list/iterable in python beforehand and desire to maintain that order.
I agree though that in case of extra-large lists python would be slower than FZF.
I agree also that some/many will expect the default FZF behaviour (live match-based re-sorting @SqrtRyan). - Pull request #23 would be more "complete" if it introduced, for example, a 'nosort' as a keyword boolean argument.
- 'True' or not declared -> '--no-sort', in order to maintain legacy compatibility
(some/many are expecting their desired order, according to previous versions of 'iterfzf' -- don't know, guessing --). - 'False' -> leave sorting to FZF.
- And then we have the case of FZF
--sort=... which can be handled by 'extra' for the time being.
- 'True' or not declared -> '--no-sort', in order to maintain legacy compatibility
Anyway, to brake legacy compatibility or not, is a decision for @dahlia to make (or by voting? I don't know the ways this project is managed).
In the meanwhile, if one doesn't want to mess with the lib's __init__.py (and do it every time it gets updated), ~~here is a monkey patch that can go into your python script: (terrible failed attempt)~~
here is an example to override the hardcoded '--no-sort':
selected = iterfzf(
iterable, multi=False, query=query, cycle=True,
__extra__=['--sort'] # override '--no-sort'
)
I'm in favor of adding a sort=True option to the iterfzf() function. Please open a pull request and I'll review it.
Just to be certain,
sort=Trueas in replacing the, till now, default--no-sort(def.True)
OR
sort=Trueas just an override for the default--no-sort(def.false)
I think the default should be sort=False.