danielfalk
[Bug] the filter ^ does not work
Hi there,
It seems like every supported filter by fzf_native works except for the prefix ^. Is there a reason why that is or is it related to my setup? Thanks
I'm not sure. I'm happy the rest of those filters work for you, but that wasn't necessarily a conscious design choice. The idea behind this extension is to be able to hit just a couple of letters and get the most likely result you want, and to do so quickly. Incorporating fzf and fzy as possible search algorithms are a pragmatic choice, with both of these algorithms being mature and performant and well-liked.
In light of this I'm not looking to prioritize any search syntax, but if there's a PR that makes it work, I'd be open to it.
I suspect it might also be due to the fact that smart-open actually performs a separate match on the filename as it does on the full path (including the filename). This is because these 2 matches are scored separately so that we can adapt the weights of each according to usage.
It looks like the ^ does work, but since it's matching on the full path, it's probably not all that useful in its current form. What would be expected behavior? That ^ would match the start of the relative path, or that it would match the start of the file name?
@danielfalk ah, nice find, you are right. it actually works just not that useful in its current form. The other filters just happen to work with a full path. very interesting. I think that itd be more intuitive to match based on relative path to git root if exist or current folder. what do you think?
You mean have the full path search always just look relative to the current directory? That would be tricky since some files can be in the history and match outside the current directory, unless cwd_only is enabled.
:thinking:
right, i forgot about that since i had always used cwd_only to true. if anything, it would be a sub option to only when cwd_only is enabled.
Same issue here with show_scores = true and the option has not effect. I found that the show_scores option gets the config value in here and not used:
https://github.com/danielfalk/smart-open.nvim/blob/7770b01ce4d551c143d7ec8589879320796621b9/lua/telescope/_extensions/smart_open/picker.lua#L33-L41
and actually the used place is an empty value: https://github.com/danielfalk/smart-open.nvim/blob/7770b01ce4d551c143d7ec8589879320796621b9/lua/telescope/_extensions/smart_open/display/make_display.lua#L122-L124
