Closed sorawee closed 4 years ago
I agree this is better.
Would it make sense to partition using (first (string-split text))
instead? Right now if the text has spaces, prioritizing won't change the order.
Thanks for the feedback! Yes, that's a good point. What it does now is to split the text by whitespaces, and for each keyword, find the weight, and then sum the weights together. Finally we sort the package list by the weight in the descending order. Does this look better?
Note that I choose to prioritize package name and description because authors and tags can already be searched via the tag systems. This leaves (@ pkg modules)
, (@ pkg name)
, (@ pkg description)
, and (@ pkg source)
, and the name and description looks most useful among these. We can add more if you think there's anything that is worth it.
Thanks again for the feedback. I just pushed a new commit. Let me know if there's any other issue.
Done.
;; NOTE: the exact match will be the first prefix lexicographically
Hang on --- all we know is that the package contains a searchable string that contains the query text. We don't know (string=? pkg-name text)
. Right?
(I think the old cond was the right one)
EDIT: the old cond is the same as the current one, but slower. string=? a b
implies string-prefix? a b
@jeapostrophe this LGTM
Thank you everyone. It is loading now.
I have been frustrated by the the current result of package search because the first few results are often irrelevant to what I'm looking for, and I need to scroll in a long page to find the package that I actually want.
This PR prioritizes the search result with 4 different priorities (lower rank comes before):
Note that it simply reorders the results. The number of results won't be affected by this PR.
Here are some examples:
Before:
After:
Before:
After: