fix: better output colors #7377
Conversation
wraithgar
force-pushed
the
gar/colors
branch
3 times, most recently
from
991ae58
to
3d0d8f0
Compare
No more grey, no more setting background colors
|
@lukekarrys rebased and fixed merge conflicts in the view command. |
| // This is the general approach to color: | ||
| // Eventually this will be exposed somewhere we can refer to these by name. | ||
| // Foreground colors only. Never set the background color. | ||
| /* | ||
| * Black # (Don't use) | ||
| * Red # Danger | ||
| * Green # Success | ||
| * Yellow # Warning | ||
| * Blue # Accent | ||
| * Magenta # Done | ||
| * Cyan # Emphasis | ||
| * White # (Don't use) | ||
| */ |
There was a problem hiding this comment.
@wraithgar : could you elaborate on why black and white are not explicitly used?
I assume it's because we'll defer to the terminal's default coloring which should hopefully allow users to colorize as desired.
There was a problem hiding this comment.
I assume it's because we'll defer to the terminal's default coloring which should hopefully allow users to colorize as desired.
It's exactly that.
Typically a terminal will configure a separate foreground and background color, discrete from the customizable 16 color palette. From what I've seen they will not also adjust black and white in the palette to be in accordance w/ the foreground/background colors.
If one wants to display with the foreground color, then print with "no" coloring. There is also bold and dim if you need those. In cases where you really do want the background color, you can inverse (I'd probably still avoid that though).
No more grey, no more setting background color.
Added the beginnings of guidance to the display layer comments.