Open HonkingGoose opened 1 year ago
I noticed this as well a few weeks ago, just didn't fully realise it. The separator splitting is unlikely to help, because the tokens are full words as far as I know (we removed "case change" separator).
Boost is on the right track, but this might be straight up a lunr ranking issue. It would be interesting to reproduce on a smaller example with mkdocs first, and then try to strip out mkdocs around it to see if lunr ranks things correctly with direct usage.
@squidfunk can you please have quick look at OP, what do you think of this issue?
We're in the midst of reworking the search. Yes, Lunr.js search result order sometimes feels indeterministic, because BM25 scoring is far from ideal for typeahead. We're going to throw out Lunr.js soon. Search is currently the huge topic I'm working on. That being said, you can try to tweak it with the separator
and boost
settings in the meantime.
Additionally, I would kindly ask you to not mention me for such things. Next time, please create a discussion or an issue in squidfunk/mkdocs-material. You can probably imagine that I get mentioned a lot and I have to budget time for communication. If you use our discussion and issue boards, other users might help you as well, which gives me more time to work on new things, including the issue in the OP. Thank you!
Sure, thanks for the heads up! And the detailed and fast response!
Thank you @squidfunk
for the response and extra information! ❤️
I don't want to "mess around" with tokenization of the search again. Search seems to work OK in general, except that you can't narrow the search results by giving more keywords. Touching the tokenization also runs the risk of breaking other parts of the search. 🙈
I'll keep this issue open, so any potential bug reporters see it. For now, the easiest thing for us is to wait for Material for MkDocs's better search.
Edit: we'll probably want to follow this upstream issue:
🙋♀️ Please see https://github.com/squidfunk/mkdocs-material/pull/6321 – feedback wanted!
What browser are you using?
Firefox
Other browser name
No response
Describe the bug
When searching on the docs site, the precise match for the
dependencyDashboard
config option sorts behind things likedependencyDashboardTitle
. Usually a precise match sorts higher than partial matches. 🙃Steps to reproduce
dependencyDashboard
.dependencyDashboard
is not the first result.dependencyDashboard
to sort higher.Additional context
Is our
separator
tokenization causing problems?We changed Material for MkDocs's default search behavior (tokenization). Maybe that's related? Here's the relevant snippet from our
mkdocs.yml
config file:Related PRs for the
separator
thing:@TWiStErRob you helped a lot before, do you want to brainstorm again? 😄
Material for MkDocs search boost feature?
Material for MkDocs has a "search boost" feature [^1], but that applies to the whole page, not just a config option. They recommend starting with a low positive value first. For example:
Boosting the "config options docs page" probably causes other sorting issues... But I wanted to mention boosting, in case it inspires any ideas. 😄
Material for MkDocs improved search in future
The Material for MkDocs maintainer is working on better search. Right now Material uses the
Lunr.js
search engine. The maintainer is going to replaceLunr.js
with something that's better for searching through a docs site. [^2][^1]: Material for MkDocs, search boost [^2]: Material for MkDocs repo, maintainer is going to improve search