-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 the second weighted path is picked #76
Comments
Hmm, I think there could be some logic about preferring the (apparently case-sensitive) prefixes... cannot quickly find it. |
I have similar cases and my guess is that matches at the beginning of the folder name are being preferred, regardless of the entry's weight: That is of course a valid metric, BUT weight should overrule the "beginning of name" rule. |
The issue is at ZLocation/ZLocation/ZLocation.Search.psm1 Lines 18 to 30 in 29cb9e6
ZLocation/ZLocation/ZLocation.Search.psm1 Line 30 in 29cb9e6
Sort-Object -Property Value, Starts -Descending should resolve this, as results will then be sorted by value first, only using the prefix if two have the same value.
|
Prefix then weight system lead to surprising behaviour eg vors#76
Oh yeah, I remember now. #26 where it started. I don't know what's really the right answer here - should the tool try to be smarter or should it try to be dumber but more predictable. |
I have been seeing the same issue and its been driving me nuts 😄 |
Any workarounds for this? |
🐛 Somehow, the second weighted path is picked.
👍 However, sometimes the first weighted path is chosen as expected.
💡 Any idea?
The text was updated successfully, but these errors were encountered: