Re: Please, paint new branch errors in RED (or any visible color)

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Dec 12, 2021, 22:27 UTC
Message-ID: <CAPig+cT-9GAtadPW-=3sVFVWyKTf9Kybs3TwSW-s0BzhsfGJyQ@mail.gmail.com>
In-Reply-To: <211212.86o85labj1.gmgdl@evledraar.gmail.com>

On Sun, Dec 12, 2021 at 4:22 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 20 quoted lines

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