Dashes in dir names break matching

[ghost]

I constantly find me and my zoxide baffled by dashes in directory names:

 % zoxide query -ls

 % mkdir a-b

 % z a-b

 a-b % cd ..

 % z ab
zoxide: no match found

 % zoxide query -ls
   4 /tmp
   4 /tmp/a-b

All the other fuzzy finders (like fzf or skim or ctrlp) work as expected (by me, at least).

Is there anything I miss?

[ajeetdsouza]

The difference is just in the querying algorithm. zoxide matches all words in order, whereas fzf matches all characters in order.

• z a-b works, because a-b occurs exactly in the name.
• z a b works, because it searches for a and then b in the name, and they both occur in order.
• z ab does not work, because ab does not occur as one word anywhere in the path name.

We did consider using a variant of fzf's algorithm, but in practice it does not work well for a tool like zoxide.

[ghost]

in practice it does not work well for a tool like zoxide

Well, it would work much better for me =)
Is there anything I can do to workaround this? Or is switching to another tool[1] the only option? From what I read, you are not open to changing this behaviour, and I am not prepared to break my habits for one tool =)

[1]: Assuming there is one that behaves like I want.

[ajeetdsouza]

Well, it would work much better for me =)

For this specific use-case, maybe, but you'd be surprised at the number of results that could show up for a query like ab. My home directory already has an a in it, so pretty much any path with a b in it is a valid result, according to fzf.

From what I read, you are not open to changing this behaviour

I'm definitely open to improving the algorithm, but I don't think fzf's algorithm is a good fit here.

To clarify -- I think fzf is an absolutely beautiful piece of software, which is why zoxide is so tightly integrated with it (see zi, zoxide remove -i, or the upcoming PR with shell completions). However, while the algorithm works extremely well for a general use case, I've found that it's suboptimal for a command like z, which requires one really good result rather than N fuzzy results.

Because the current algorithm is "stricter", I can usually get almost anywhere on my filesystem with a maximum query size of 4 characters, and it's almost never wrong. However, with fzf I usually find myself having to scroll down or enter more characters to get to the correct result.

Is there anything I can do to workaround this?

Absolutely! One good thing that zoxide offers you IMO is a thoroughly documented CLI, for exactly this use case. A lot of people who want custom behaviour simply write their own z function. In your case, assuming you use zsh, I would do something like this:

function z() {
  local result
  result="$(zoxide query -l | fzf --exit-0 --select-1 --query "$*")" && cd "$result"
}

[lefth]

I wonder if this is a common use case? We certainly could do the initial filtering after removing non-word characters (unless the keywords also contain non-word characters). If we kept the directory separators, I wonder if this would yield more positive results than mistakes. I haven't used zoxide very long, so I don't have intuition about this.

[ghost]

Thanks, @ajeetdsouza, this is a great idea, I didn't think about rewriting z(), I'll try cooking something up. Stripping home dir prefix seems especially useful (could be implemented in zoxide, I think).

[ajeetdsouza]

No problem! I've added your suggestion into another thread where we're taking a look at potential improvements for the querying algorithm. Feel free to comment here if you have any further questions.

[eugenesvk]

I appreciate the strive for precision (vs fzf, which has a picker to resolve it), but still maybe the algorithm could be somehow relaxed in less ambiguous cases than just 2 ab chars that would match anything? For example, I had a dir

• test-gui and trying to navigate to it via
• testgui failed, which was surprising

This is an exact match except for the -, so maybe there could be a "% contiguous covered" factor of the query vs the de-dashed database (so 100% in this case for the name, but could allow for a smaller number)