JuliaDocs
added SearchRecord custom functions for at-blocks
this is an attempt to solve and potentially close #1929 my thought process was that right now the SearchRecord objects are created and added to the search index which are very general so I made custom function for adding SearchRecords and add special handling for MultiOutput which is @example block, MultiCodeBlock which is the @repl block and EvalNode which is the @eval block
I can add the changelog and will fix the linting issues once we decide what is the most optimal solution :)
Just thinking out loud here. The methods you're adding, they are getting called here:
https://github.com/JuliaDocs/Documenter.jl/blob/4328aec711dd3ee04d1989c796b241f547962fcd/src/html/HTMLWriter.jl#L1683-L1684
It feels like what we want is sometimes not to write any SearchRecord here. For example, for at-docs, we kinda get duplicate entries right now, one for the at-docs source, and one for the actual docstring.
{
"location": "",
"page": "Example Site",
"title": "Example Site",
"text": "Main.DocString",
"category": "page"
},
{
"location": "#DocString",
"page": "Example Site",
"title": "DocString",
"text": "Docstring\n\n\n\n\n\n",
"category": "constant"
}
The second one (actual docstring content) gets pushed here:
https://github.com/JuliaDocs/Documenter.jl/blob/4328aec711dd3ee04d1989c796b241f547962fcd/src/html/HTMLWriter.jl#L1775-L1783
So what I think we might be able to do is change these methods to functions (searchrecord, to differentiate from the constructor), which sometimes just returns a nothing. We'll add a searchrecord method for e.g. DocsNode to return nothing, and then in the first loop at the top, we just exclude any nothings. That should give us an easy way to exclude nodes at this level.
Just one more note: as I was playing around with this PR, and to actually see what ends up in the search index, I put together a small toy build that also prettyfies the index, in case that might be useful: https://github.com/JuliaDocs/Documenter.jl/commit/becf65c8c91e6c2c774329c0618c153a5c18a2ae
In general (but probably not in this PR, to not scope creep this), I think we want some explicit tests for the search index generation, like with reference output etc.
Just one more note: as I was playing around with this PR, and to actually see what ends up in the search index, I put together a small toy build that also prettyfies the index, in case that might be useful: becf65c
In general (but probably not in this PR, to not scope creep this), I think we want some explicit tests for the search index generation, like with reference output etc.
this is a great idea, I will make a new PR for tests after this PR's completion.
this time I made a should_index_for_search function checking for at-blocks and only added the one which were not at blocks but still I don't think this issue is solved
I have tested it locally it does not add duplicated to the search index, I will add changelog entries once we decide to go ahead with this approach
It would be nice to get this over the finish line. I've just merged master into this branch to get CI to run again.
