HTML Search: fixup: include partially-matched document titles in search results.

[jayaddison]

Feature or Bugfix

• Bugfix

Purpose

• Fixes a bug that prevents partially-matched titles from Sphinx documentation projects from appearing during search results (for example, a section titled sphinx_utils module should be found when searching for sphinx, but currently is not).

Detail

• The bug is that after finding a partially-matching title, a title-term-index lookup was performed using the word from the user query (sphinx, to continue the example) instead of the partially-matching term (sphinx_utils).

Relates

• Depends upon either:
  • HTML Search: Fix partial matches overwriting full matches #11958
  • OR
  • [HTML search] correction for scoring of search terms that only appear in document indexed with id zero. #12037
• Resolves HTML Search: partially-matched titles are not included in search results. #12040.

[wlach]

Looks right to me

[jayaddison]

Thanks @wlach!

[picnixz]

Ok, I'm just picking a random PR on search to ask something:

@jayaddison @wlach Could you create an issue where you gather all the search-related PRs and the ones that should be merged (or alternatives)? like, which one should I focus first etc, whether one PR should be merged before another or not etc? They are a bit spread everywhere and it's awfully hard for me to pick the correct one.

[jayaddison]

Hi @picnixz - the remaining pull requests can be considered independently of each other.

I've repurposed the awaiting response issue label to tag the pull requests that are awaiting review.

Logically I think #11578 would be the first one to merge, followed by #12041.

Two of the pull requests are competing/alternate solutions to the same problem; we think we've decided on our preferred pull request -- but even so, if possible, I'd like if someone with long-term experience of the search code to catch any mistakes with that (because my sense is that it could be trickier than some other changes to rollback/revert problems).

[picnixz]

I've repurposed the awaiting response issue label to tag the pull requests that are awaiting review.

I can create another label for that (awaiting:review)

[jayaddison]

Logically I think #11578 would be the first one to merge, followed by #12041.

@picnixz ah - I noticed that you were awaiting further review from @AA-Turner on #11578. In that case I think #12041 is the one to start with (hopefully you notice this in time).

I've repurposed the awaiting response issue label to tag the pull requests that are awaiting review.

I can create another label for that (awaiting:review)

Thanks!

[picnixz]

So 12041 is actually this one. Just wondering, but the partially matched documents are put after those with exact match, right?

[jayaddison]

Correct, yep. Exact-match titles are given a score of 15, and with this change title partial-matches are given a score of 7 (after being omitted entirely due to the bug).

That does make me think that ideally one of the duplicate-result fixes might be better to merge first.. only for people who are installing from our git master branch instead of a release. Fewer duplicates first, then additional results. Do we consider those cases, or do we care more about the packaged release result?

[picnixz]

Ok, then this PR is fine (just resolve the conflicts and I'll merge it)

[jayaddison]

Nearly-ready, but I think I'll block/wait on this until the JS search tests are refactored.

[picnixz]

@jayaddison I know you said that you would be offline but since nothing changed since last time (except conflicts and CHANGES), I assume that everything is fine, right? if so, I'll merge it this afternoon.

[jayaddison]

@picnixz yep; this is ready and can be merged without other dependencies, so I felt it could be good to mark as ready for review while I'm taking a rest. Thank you.

[picnixz]

Thank you both!