Search: headings which contain inline code are incomplete when displayed in search results

[sarcastro]

Context

No response

Bug description

When a heading contains inline code and search terms are contained within the heading itself, only the portions of the heading which matched the terms are displayed to the user, with the rest of the heading being omitted entirely.

The result of this is incomplete information being shown to the user and, depending on the text that's missing, can display confusing and/or factually incorrect results to the user.

Note: If the matched search term(s) are contained in the content beneath the heading only (i.e. not within the heading itself) then the headings are displayed properly.

Related links

• Reporting a bug
• I searched the documentation, discussions and issues to determine if this is expected behaviour and the closest I'm able to find is the Built-in typeset plugin documentation, which this behaviour does seem to contradict.

Reproduction

While I'm happy to provide this if needed, I don't think it provides any benefit in this particular case as the issue is easily reproducible without any special configuration and easily demonstrable using the official project documentation. In lieu of a reproduction .zip, I took screenshots of the official documentation and took care to ensure that they include the URL and version number in them. As such, these can be used as additional examples of steps of steps to reproduce.

Here are screenshots showing numerous ways the Creating a .zip file section in the official project documentation can be displayed depending on the search terms. Section is located on the Creating a reproduction page, coincidentally enough.

❌ Search for zip shows only Creating a .zip:

❌ Searching for file shows only file:

✔ Searching for text beneath shows the full heading properly (Creating a .zip file):

Here's another example, showing the same behaviour on a page heading (rather than section heading), using the Using git sparse-checkout for faster documentation builds page in the official project documentation:

❌ Searching for git sp shows only Using git sparse-checkout:

❌ Searching for docum shows only for faster documentation builds:

✔ As with the example above, searching for text beneath it shows the full heading correctly (Using git sparse-checkout for faster documentation builds):

If you'd still like a reproduction .zip, please just let me know and I'll be happy to provide one.

Steps to reproduce

1. Use inline code in a heading in a markdown file in the documentation.

e.g.
# PLEASE `DO` `NOT` TRY THIS AT HOME!!

2. Perform a search using the built-in search plugin.

A search for home results in: TRY THIS AT HOME:

A search for please results in: PLEASE DO:

(As a side note, I do see that the exclamation marks are missing too but I haven't investigated it well enough yet to be confident it's a bug. )

Browser

No response

Before submitting

• I have read and followed the bug reporting guidelines.
• I have attached links to the documentation, and possibly related issues and discussions.
• I assure that I have removed all customizations before submitting this bug report.
• I have attached a .zip file with a minimal reproduction.

[squidfunk]

Thanks for reporting. We're happy to look into it, but:

While I'm happy to provide this if needed, I don't think it provides any benefit in this particular case as the issue is easily reproducible without any special configuration and easily demonstrable using the official project documentation.

Yes, it is necessary. You checked that you carefully read our bug reporting guide, including:

Why we need this: if an issue contains no minimal reproduction or just a link to a repository with thousands of files, the maintainers would need to invest a lot of time into trying to recreate the right conditions to even inspect the bug, let alone fix it.

The moment you provide it, we'll look into it.

[sarcastro]

9.4.3-inline-code-headings.zip

Here it is. I thought I could get away without it as the conditions/example were already present in the documentation but I do realize the configuration isn't minimal.

Note to self: "If you take shortcuts, you get cut short." -Gary Busey

[squidfunk]

Fixed in 57e598b. This was tricky, so I improved the debugging launch configurations in the process in dcf5a80, 34aad07 and 790a446 ☺️ We now explicitly tell only to retrieve partial results for text, and to include the entire line for all other fields. This is kind of a bandaid and will be fixed in the new search, but for now we have to make this distinction. My testing shows that the errors are gone and the entire line is returned at all times.

[squidfunk]

By the way, the reproduction was perfect for debugging, so many thanks for investing the time into it. Without it, I would have had to create one myself first, since debugging the search on a large index as we have it on our own docs is absolutely impractical. Having a small, concise reproduction for testing made fixing this straight-forward.

[squidfunk]

Released as part of 9.4.4.

[sarcastro]

By the way, the reproduction was perfect for debugging, so many thanks for investing the time into it. Without it, I would have had to create one myself first, since debugging the search on a large index as we have it on our own docs is absolutely impractical. Having a small, concise reproduction for testing made fixing this straight-forward.

Your process for creating the reproduction made it a piece of cake and actually took me less time than my initial screenshots did. Thanks a bunch for the quick fix, much appreciated!