Bug: Incorrect search results from `z` and `z -l`

[zachriggle]

Today, z took me to the wrong directory! It was a valid directory, but not the one that likely should have been selected. I wanted the one with the score 219, I got one with a score of 4.

Removing the score-4 entry from the list reverted to correct behavior. Not sure how I can help out to debug this (since I can't provide my ~/.z file (it's on a work computer) but thought it was still worth reporting.

It might be useful to have a -v option to z that explains why a particular directory was selected, to help diagnose this. I think in this case, it was due to the "recent access" being used, rather than "rank". I'll update my shell to alias z=z -r to avoid this in the future.

What makes me think this is an ACTUAL bug, is that the first z -l does not show all of the other matches, they only show up after removing that specific directory.

$ z omni

$ pwd
/Applications/OmniFocus 3.4.1.app

$ z -l omni
4          /Applications/OmniFocus 3.4.1.app

$ z -x .

$  z -l omni
1.10       /Users/zachriggle/omni2/omni
1.58       /Users/zachriggle/omni/completions
2.79       /Users/zachriggle/omni2
5.86       /Users/zachriggle/Library/Containers/com.omnigroup.OmniFocus3
13.37      /Users/zachriggle/omni/omni
219.10     /Users/zachriggle/omni

[agkozak]

First, you might want to download the latest version of ZSH-z so that we can be sure that we're comparing apples to apples. I can see from the way that your ranks are displayed that you're using an older version.

Were you using a special z alias before?

Are you using any of the special Settings?

[zachriggle]

I was working on a branch based on e138de5 with minor changes (1 additional "if" statement to prefer case-insensitive matches over case-sensitive matches). So not particularly recent, I'll re-file a bug if it happens again.

It looks like that has been implemented with ZSHZ_CASE=smart so I don't need that old branch anymore.