Allow renderers to override _any_color_fmt.

[asinghvi17]

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 writer_supports_ansicolor instead of a hardcoded type check; that function can then be extended.

[goerz]

Seems okay to me. Of course, there is still the fact that this is 100% internal. If we had an official stable plugin API it would be worth thinking about whether a function like this would be part of that plugin API. If it was, the function would have to have a non-underscore name (format_supports_color?) and a docstring that describes exactly what that a writer promises when it claims format_supports_color as true.

[mortenpi]

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.

[asinghvi17]

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.
"""

[mortenpi]

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?

[fingolfin]

@asinghvi17 are you still interested in working on this?

[asinghvi17]

Things should be working after this commit.

[asinghvi17]

Let's see if this works instead

[asinghvi17]

Let's see if this works instead

[asinghvi17]

Maybe using HTML is messing something up here? But I have no clue what.

[goerz]

LGTM, apart from the trailing whitespace, which should be trivial to fix ;-)

[asinghvi17]

@lazarusA after this PR is released, we can deprecate the @ansi block in Vitepress

[goerz]

Okay, this should be good now :-)

[mortenpi]

LGTM as well, thank you! I took the liberty of putting the new function into the manual as well, under the public API section.