Allow customising fundamental code colours for the default theme?
Such as the values hard-coded in theme_code().
Also if the background type (dark vs light) can't be determined and hasn't been set by the user, it's probably best to not use background colours instead of assuming a light or dark background.
This can be customised with:
options(
cli.user_theme = list(
span.code = list("background-color" = "#3B4252", color = "#E5E9F0")
)
)
But it would still be nice to disable the default theme_code() values when the background can't be figured out.
Right now the default themes have colors of three kinds:
- can be configured easily, e.g. the color of a package name is just the theme
list(span.pkg = "yellow"). - the color is mixed up with the generated text, so you need to update both, e.g.
This is not great, and I'll (possibly later) create a separate tag for the tick mark, so that one can only change its colors like this:list(".alert-success" = list( before = function() paste0(cli::col_yellow(cli::symbol$tick), " ") ),list(".alert-success .mark" = list(color = "yellow") - the color and the generated text is even more mixed up, there is one such case, the header line of
<h1>which is created internally withrule()and a fixed color. This should be similarly separated.
Should I open a separate issue for the following concern?
Also if the background type (dark vs light) can't be determined and hasn't been set by the user, it's probably best to not use background colours instead of assuming a light or dark background.
I removed the background colors from the default theme, so no need.
oh. Was this because of concerns background colours would not fit well into all themes?
This will require updating the rlang doc about cli theming.
You can still set a background if you want. But by default there is none. It was only used at one place, anyway.
I'll leave this out for now, needs some more thinking.