Directory depth penalty

[chamini2]

I understand the scoring algorithm uses some sort of penalty to a file if it was too deep inside the directory structure, but sometimes this doesn't make sense, I'll post an example and explain:

As you can see, it now matches the probably expected file, but when we want to filter by saying "it's in the controllers/ directory"

It penalizes the application_controller result because directory depth, or at least that's my guess. So why not start the deepness count of at the first directory match, in this case in the controllers/ directory.

[winstliu]

Have you tried the new alternate scoring method present in Atom 1.1.0? The new scoring method uses fuzzaldrin-plus.

[jeancroy]

So why not start the deepness count of at the first directory match, in this case in the controllers/ directory ?

From what I understand, directory dept penalty can be useful because user may not be aware of what file exist at very deep level. Additionally they may exist as vendor dependency (for example nested node_modules)

Deep path can trigger match length penalty, but not necessarily. Let's take for example : etc/lib/src/config/application_config.cfg. Your proposal would then make that file as good as any file one folder down the root, thus making the above directory depth likelyhood useless.

BTW your proposal would basically be equivalent to minimizing match spread which is an useful but different metric.

I hope that cover the why.

[chamini2]

This happens using the alternate scoring option, thought I stated it in the original post.

But I do understand the reason @jeancroy, makes sense, thanks for the response.

[jeancroy]

Ok added a test, your use-case works without any change on fuzzaldrin-plus@0.2.0 which adjust some weights vs what is currently in atom.

Issue should probably be closed, if you have another issue please open it on fuzzaldrin-plus

[chamini2]

The test you added is missing the failing case:

 expect(bestMatch(candidates, 'con/appcon')).toBe candidates[1]

[jeancroy]

Ok sorry for that, I'm working on it. Could you open an issue in the proper repo ? (fuzzaldrin-plus, not classic fuzzaldrin)