On Sun, Dec 12, 2021 at 4:22 PM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> Yes, I think it's a bug if we add any such coloring that isn't
> configurable via the usual color.* configuration. Although in this case
> it's usage.c. So perhaps "color.usage" (as in usage.c). But that squats
> on any future hypothetical "git usage". So maybe "color.coreUsage" (a
> "color.core.usage" would squat on any future "color.core.usage.<slot>"
> (i.e. there's no 4-level keys)>
>
> > Making it opt-in is even better, but it is my personal taste.
>
> *nod*. I'll see how it turns out. FWIW I think that it's probably too
> over-colored to do:
>
> <RED>fatal: the message</RED>
>
> And it's probably better to just do:
>
> <RED>fatal</RED>: the message
>
> But I'll see once we have actual examples. The advice output is
> fully-colored now. I.e. "hint: message", not just the "hint" part...
As a minor bikeshedding datapoint, a script I wrote a few years ago
highlights outdated entries in a larger output. The highlighting is
applied only to a single word ("outdated") on one line related to the
item, and I found that my eye would regularly glide right over the
highlighting in the somewhat voluminous output without ever seeing the
highlight. Very recently, I changed it to highlight the entire line,
and that has helped me take more notice of it (though, admittedly, I
still sometimes still overlook the highlighted item).
