Strange search behavior about slate

[lord]

Seems to be finding it for me. The odd thing is that it also somehow is matching the "Automating mobile web apps" section as well...hmmm.

[bootstraponline]

This is what I see on Chrome. It looks like a bug to me.

[lord]

Hmm, that is the behavior I would expect, it just filters the sections down to the sections containing the search query, but the the optimal behavior...it would be nice if the view skipped down to the first search result. I'll open a separate feature request for this.

[bootstraponline]

Automating mobile web apps doesn't contain the string write docs so I think it should be hidden? I'm expecting only How to write docs to be displayed on the side bar.

[lord]

Hmm. I think Automating mobile web apps contains both the words "write" and "docs", and so the fuzzy searching is picking it up. At least, that's my guess.

[bootstraponline]

Yes, I think that's the bug. It's doing a search for write AND docs when the expected search is "write docs" the complete literal string. Compare the current behavior to the Google chrome built in search.

If I changed the search behavior to match the Google chrome search, would you accept a pull request?

[lord]

Hmm, I'd rather not make the search quite as blunt as the Google Chrome search...it seems that Lunr gives us a score property, what if we just sorted the sections by that, so the best-matching section appears first? That would make "how to write docs" appear at the very top, and the less-well-matching results appear farther down the page.

[bootstraponline]

I was just about to comment. Enforcing a minimum score resolves the issue.

2 results! all.js:3143
Object {ref: "how-to-write-docs", score: 0.4679618817634447} all.js:3145
Object {ref: "automating-mobile-web-apps", score: 0.00003974502238349404}

The unexpected matches have a very low score.

[lord]

Perfect! If you find a nice threshold, I would be glad to accept a pull request that sets a minimum.