added SearchRecord custom functions for at-blocks#2672
added SearchRecord custom functions for at-blocks#2672Rahban1 wants to merge 5 commits intoJuliaDocs:masterfrom
Conversation
|
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: Documenter.jl/src/html/HTMLWriter.jl Lines 1683 to 1684 in 4328aec It feels like what we want is sometimes not to write any {
"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: Documenter.jl/src/html/HTMLWriter.jl Lines 1775 to 1783 in 4328aec So what I think we might be able to do is change these methods to functions ( |
| output_text = "" | ||
| for child in children_array[2:end] | ||
| if isa(child.element, Documenter.MultiOutputElement) && isa(child.element.element, Dict) | ||
| for mime in [MIME"text/plain"(), MIME"text/markdown"(), MIME"text/html"()] | ||
| if haskey(child.element.element, mime) | ||
| output_text *= string(child.element.element[mime]) * " " | ||
| break | ||
| end | ||
| end | ||
| else | ||
| output_text *= mdflatten(child) * " " | ||
| end |
There was a problem hiding this comment.
So, for at-example blocks, we render both the input and the output. We probably want to put the source code into the index as well?
In general, though, I wonder if it's better to just add the search index entries in the actual domify methods, like here:
Documenter.jl/src/html/HTMLWriter.jl
Lines 2394 to 2527 in 4328aec
The bonus is that the "rendered" output of a block is already present, so it would reduce duplication I think.
X-ref #2672 (comment) about how to remove the other entries.
|
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 |
| """ | ||
| Filter function to prevent duplicate search entries. | ||
| """ | ||
| function should_index_for_search(navnode, node, element) |
There was a problem hiding this comment.
I think it should be sufficient to just check the type, no need to introspect into the objects? So something as simple as this should be enough probably:
exclude_from_search_index(element) = typeof(element) in (Documenter.MultiOutputElement, Documenter.MultiCodeBlock, Documenter.EvalNode)|
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 |
|
Needs a rebase, now that your other PR #2762 has been merged :-/ |

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