-
-
Notifications
You must be signed in to change notification settings - Fork 58
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
[BUG/Feature Request] Files with exact match aren't on top of list #289
Comments
That's more of a consequence of the design: when you search for Though it should be easy to implement a score boost when the filename contains the exact query (maybe with a few constraints like >= 2 tokens or >= 5 chars) |
I'm interested in seeing this as well. It seems like if the first three tokens are a direct match that would be sufficient? @scambier if you want I'll look into it. |
When you search for "Theorem 2.8", the tokens will be Kinda like we're filtering documents for parts in quotes here, we can check if some documents contain the raw query, and boost their score. You're welcome to take a loot at it 👐 |
@scambier, did you think to use some string metric algorithm, like Demarau Levenshtein distance or something similar? Here you have a few more suggestions. What do you think about it? BTW. This may be useful as well. |
Problem description:
Not sure if this is a bug or by design, but I would think the files starting with the substring would be on top:
I tried playing with the various weights but couldn't get both of the "3.1."s on top.
This of course happens in various searches, not just this.
Your environment:
Things to try:
The text was updated successfully, but these errors were encountered: