-
Notifications
You must be signed in to change notification settings - Fork 478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow renderers to override _any_color_fmt
.
#2490
base: master
Are you sure you want to change the base?
Conversation
This has uses for DocumenterMarkdown as well as DocumenterVitepress, and will allow us to get rid of the current `@ansi` block formulation.
_any_color_fmt
a method which can be overridden._any_color_fmt
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
idx === nothing && return false | ||
return doc.user.format[idx].ansicolor | ||
end | ||
|
||
# General fallback. | ||
_is_color_fmt(::Documenter.Writer) = false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_is_color_fmt
doesn't seem like the best name for this function. Maybe _format_supports_color
?
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 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.
""" |
We're moving away from the submodules. Re the docstring: generally, looks fine. Though I think the main difference will be that the |
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.