How to order by shortest match?

[palsivertsen]

Is there any way to configure the ordering of results?

I use the ALT-C shortcut in bash to quickly navigate my folders. However, for certain paths (seems to be related to -), I get weird suggestions to my queries.

Example
I have the following directory structure:

$ tree
.
├── another-project
│   └── with
│       └── a
│           └── sub
│               └── directory
│                   └── called
│                       └── myproject
└── my-project

9 directories, 0 files

... and I want to navigate to my-project, but I can't remember the exact name so I type myject and expect the my-project directory to rank highest, since it's the shortest match. However fzf ranks the folder I want last. This is especially annoying when I have lots of results and the directory I want is often not even on screen.

Even if I try to be more specific I do not get the correct result:

If it was sorted the other way around I could be more specific in my query to narrow the results.

[LangLangBart]

Have you tried setting FZF_ALT_C_OPTS¹ with options from the fzf man page, like --no-sort² or --tiebreak?

export FZF_ALT_C_OPTS="--no-sort --tiebreak=length,begin,index"

The maintainer is currently up in works and I am not too confident in my answer, he might weigh in when he comes back.
Alternative reading material: fzf: Search syntax | junegunn.choi.

Footnotes

1. GitHub - junegunn/fzf: 🌸 A command-line fuzzy finder ↩

2. Unexpected reordering when using --scheme=history · Issue #3645 · junegunn/fzf · GitHub ↩

[palsivertsen]

Those options is not what I'm looking for. I tried using the --no-sort option and sorting the results before calling fzf with something like this:

find -type d 2> /dev/null | sort | fzf --no-sort

Unsurprisingly the performance is bad and the result is not what I want.

I don't think this is related to tiebreaks either, it's about sorting the results. An option like this maybe:

--sort=begin,length

[lamyergeier]

fzf --tiebreak=chunk worked for me.

[palsivertsen]

fzf --tiebreak=chunk worked for me.

Did you do something different than me? Here's what I did:

[ipwnponies]

--tiebreak only has an effect if the score is the same (#1403 (comment)):

Since we updated the ranking algorithm, ties are rare and --tiebreak has lost most of its significance. I've even considered removing the option because it can be too confusing. --tiebreak=index would be a good default then.

The scoring is not the same, using myject. Requisite reading on how the scoring algorithm works:

fzf/src/algo/algo.go

Lines 39 to 78 in e491770

	Scoring criteria
	----------------
	- We prefer matches at special positions, such as the start of a word, or
	uppercase character in camelCase words.
	- That is, we prefer an occurrence of the pattern with more characters
	matching at special positions, even if the total match length is longer.
	e.g. "fuzzyfinder" vs. "fuzzy-finder" on "ff"
	````````````
	- Also, if the first character in the pattern appears at one of the special
	positions, the bonus point for the position is multiplied by a constant
	as it is extremely likely that the first character in the typed pattern
	has more significance than the rest.
	e.g. "fo-bar" vs. "foob-r" on "br"
	``````
	- But since fzf is still a fuzzy finder, not an acronym finder, we should also
	consider the total length of the matched substring. This is why we have the
	gap penalty. The gap penalty increases as the length of the gap (distance
	between the matching characters) increases, so the effect of the bonus is
	eventually cancelled at some point.
	e.g. "fuzzyfinder" vs. "fuzzy-blurry-finder" on "ff"
	```````````
	- Consequently, it is crucial to find the right balance between the bonus
	and the gap penalty. The parameters were chosen that the bonus is cancelled
	when the gap size increases beyond 8 characters.
	- The bonus mechanism can have the undesirable side effect where consecutive
	matches are ranked lower than the ones with gaps.
	e.g. "foobar" vs. "foo-bar" on "foob"
	```````
	- To correct this anomaly, we also give extra bonus point to each character
	in a consecutive matching chunk.
	e.g. "foobar" vs. "foo-bar" on "foob"
	``````
	- The amount of consecutive bonus is primarily determined by the bonus of the
	first character in the chunk.
	e.g. "foobar" vs. "out-of-bound" on "oob"
	````````````
	*/

A small repro is:

printf '%s\n' my-project myproject | FZF_DEFAULT_OPTS= fzf

my-project has two special positions (word boundary-ish), m and p, while myproject only has one. So any query that includes p will score higher. i.e. Start by crafting a query that leans toward an acronym finder.

mject scores higher for myproject:

• in my-project, it hits the m bonus but ject is fuzzy search
• ditto for myproject. However, m and ject are closer together. I don't see where in the code this is, but have empirically tested it.

So to hit my-project, the differentiator will be including both m and p. However myp doesn't work because it is an exact substring of myproject, so scores even higher (consecutive match scores strongly)! Your only choice is to start the query with mp....

With all that being said, I realize this won't satisfy your use case. Since it's unlikely for you to knowingly produce a tie (--tiebreak is non-functional), therefore your only choice is to manipulate the scoring. But to manipulate the scoring, you'd need to already know what you're searching for in the first place (i.e. was it my-project or myproject or myProject).
And the scoring is static, there's no user adjustable weightings.
Note that the cd widget uses --scheme path which slightly alters how tokenization behaves but I'm assuming that's not hte root of your issue.

fzf/shell/key-bindings.bash

Line 52 in e491770

FZF_DEFAULT_OPTS=$(__fzf_defaults "--reverse --walker=dir,follow,hidden --scheme=path" "${FZF_ALT_C_OPTS-} +m") \

Take everything I said with a grain of salt, I am not very adept at reading go so I may miss nuances. Mostly a combination of experimentation and cursory glance at the scoring algorithm.

[amundhov]

Reading through this I had a thought on a way to frame the issue brought up by @palsivertsen. The most likely problem is when your query matches either

1. file-pattern which is likely to be included in lots of different places (such as init.py in python, auto-generated file, etc ).
2. directory with a bunch of files

In that case you will have a lot of similar candidates crowding out the other results.
Ideally, you want some way to fit the most diverse set of matches above the fold.

Maybe there could be some heuristic to group matches and organize them in some way. Probably looking at the histogram of scores in some 'degenerate' cases is a good idea.

If you were looking for a file which happened to match higher against category 1 ( Say init.py ), you want a simple way to skip/hide those matches.

If you actually wanted to match a category 1 file like init.py and got lots of matches you're going to need to make a new query to drill down. In that case what you really need are the possible top-level directories providing those kind of files.