JuliaDocs
Allow renderers to override `_any_color_fmt`.
This function is used to decide whether to emit ANSI colored output to the output fields of @example blocks.
This has uses for DocumenterMarkdown as well as DocumenterVitepress, and will allow us to get rid of the current @ansi block formulation.
The PR simply changes the check in _any_color_fmt to calling a function instead of a hardcoded type check; that function can then be extended.
I agree with Michael. I'm fine with this change as well, but in the current form, it would not have any guarantees of a public API. But I feel this could be turned into a public API as well, if we can articulate a precise docstring for it.
Thanks for the feedback!
I would love to make this a public API - if so, it would probably go in Documenter.Writers, and perhaps the name supports_ansicolor would work? That would also remove the need for all writers to have an ansicolor field if they do support it.
Perhaps a docstring like:
"""
supports_ansicolor(writer::Documenter.Writer)::Bool
Returns `true` if the writer `writer` accepts ANSI colored input from Documenter, or `false` if it does not.
Defaults to `false`.
This is mainly used to color the output of `@example` and `@repl` blocks.
"""
it would probably go in
Documenter.Writers
We're moving away from the submodules. Documenter.writer_supports_ansicolor would probably be a good name.
Re the docstring: generally, looks fine. Though I think the main difference will be that the show and other IO methods will be called with an color=true IOContext?
@lazarusA after this PR is released, we can deprecate the @ansi block in Vitepress