search.show-item-context provides context too infrequently

[aronatkins]

Bug description

Given a hierarchical website configured with search.show-item-context: true, search results are not often presented with a path.

Steps to reproduce

Using the attached project:

project.tar.gz

Searching within this project for "admin", only one result is presented with a path:

Expected behavior

Most documents in a hierarchical site should include page path.

Actual behavior

Few documents in a hierarchical site include page path.

Your environment

macOS Sonoma 14.1.1
Quarto 1.4.518

Quarto check output

Quarto 1.4.518
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.9: OK
      Dart Sass version 1.69.5: OK
      Deno version 1.37.2: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.4.518
      Path: /Users/aron/Downloads/quarto-1.4.518/bin

[✓] Checking tools....................OK
      TinyTeX: (external install)
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/aron/Library/TinyTeX/bin/universal-darwin
      Version: 2022

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.9.6
      Path: /Library/Developer/CommandLineTools/usr/bin/python3
      Jupyter: (None)

      Jupyter is not available in this Python installation.
      Install with python3 -m pip install jupyter

[✓] Checking R installation...........OK
      Version: 4.3.1
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/library
      knitr: 1.44
      rmarkdown: 2.25

[✓] Checking Knitr engine render......OK

[dragonstyle]

I'm seeing something slightly different:

which I think appears correct. We do some caching of search results during render, so it's possible the difference is a bug in refreshing state. Does the above match what you'd expect?

[aronatkins]

Interesting. I just got the same results as you. I'll try to fully reset the context of my full doc-set and report back to see if the breadcrumbs improve there, too.

The sub > overview loses the fact that the page is included in the "admin guide". This is more obvious with the search "sub", since that term is across build nested guides.

In the project I included, the page titles make the ambiguity less obvious..

To avoid the path ambiguity, the root level should be included.

The Quarto site search shows this lack of top-level breadcrumb, too, though the structure of the "Guide" makes the lack of top-level path less apparent. The top result is nested beneath the "Extensions" hierarchy.

Maybe the right answer is to introduce more (artificial) hierarchy into the nav?

[aronatkins]

I just fully purged my old _site directory and am seeing many more hierarchical paths. I did not realize that the search results were not fully up-to-date after starting a quarto preview session.

[dragonstyle]

I just fully purged my old _site directory and am seeing many more hierarchical paths. I did not realize that the search results were not fully up-to-date after starting a quarto preview session.

We re-generate the search index when we render a document, but do so incrementally. I complete render would update the whole thing... This might be one of the more unusual cases where you could update a global document which invalidates the search index for a bunch of documents (since it holds their path). I'll give some thought to whether we can / should invalidate the search index in just this case.

[aronatkins]

It was definitely the case that I had some Quarto 1.3 results in my _site directory and also was playing with search.show-item-context while experimenting with Quarto 1.4, so a very dirty state.

[dragonstyle]

Ok I worked through connecting the navbar parent to the sidebar and the results are much better. I'll kick off a build and hopefully this looks more reasonable now! Thx for reporting / catching!