[Toybox] Question about --color

[enh]

On Sat, Aug 13, 2022 at 3:42 AM Rob Landley <rob at landley.net> wrote:

> On 8/10/22 10:02, enh wrote:
> > i don't have a _technical_ reason, but i will say i've always hated `ls
> --color`
> > and the first thing i do on a new OS install is _delete_ those default
> aliases.
> >
> > (actually, trying to translate that into a technical reason: you can't
> ask
> > terminals what the rgb value for an ansi color is,
>
> Do you know about the new 24-bit color escape sequences? I played with
> them a
> bit last year:
>
>   https://landley.net/notes-2021.html#06-10-2021
>
> It's printf("\e[38;2;%d;%d;%dm", red, green, blue); to set the foreground
> color
> (each is 0-255), and 48;2 instead of 38;2 to set the background color.
>

yeah, i use them all the time in hobby projects. i have a very fetching
tetris for terminals, and a tty-based editor that looks remarkably like
visual studio code. (as you know, _starting_ things is easy. _finishing_
them is the hard part. i have so many proof of concepts for "tty-based
editor that feels like it's from this century", but it's the second 80%
that i never get round to.)


> > and you can't even ask
> > whether there's a dark-on-light or light-on-dark scheme, so you can't
> really
> > guarantee that your default colors are at all visible. see also:
> accessibility
> > issues for people with various kinds of color vision deficiencies.)
>
> Part of my new install checklist is xfce terminal
> edit->preferences->colors to
> make the background be ACTUALLY BLACK (rather than just dark grey) and
> bump up
> their idea of "dark blue" a little bit so it's legible.
>
> There's an LS_COLORS environment variable, but that's the standard gnu
> failure
> mode of playing whack-a-mole on each command instead of having global
> consistent
> behavior. (We talked about that.)
>
> > since i don't have any issues with red or green on a dark background in
> any
> > terminal i've used,
>
> Except the most common kind of colorblindness is red/green. :)
>

yeah, but like you said above, the main issue for non-colorblind folks is
just legibility... it's blues and magentas on dark, or cyans and yellows on
light, usually. (though since "yellow" is sometimes more of a brown to
avoid the legibility-on-light problem, it can cause legibility-on-dark
problems!)


> They have colorblind correction glasses these days, but they're still under
> patent so they're many hundred of dollars per pair. Entrapta, Encarta...
> ah:
>
> https://www.youtube.com/watch?v=WCcxwieuDH0
>
> > i don't actually mind `diff --color` and whenever a new git
> > install asks me whether i can see the diff i just choose "yeah,
> whatever". it's
> > blue/magenta on dark or yellow/green on light that i find problematic.
> (what rgb
> > values "yellow" actually comes out as varies the most widely between
> terminals
> > of any color.)
>
> In theory there's some environment variable that can provide a color
> mapping to
> override the defaults. In practice, the existence of the "dircolors"
> command is
> Peak Gnu. It ONLY sets the colors for ls, not any other command. I.E.
> their ls
> implementation has a whole supporting command to set an environment
> variable for it.
>
> As an aside, the "apropos" command is meta-annoying because neither
> "apropos
> color" nor "apropos colors" mentions ls (it's not searching the CONTENTS
> of the
> man page, just some decription field), and the meta part is that apropos
> --help
> does not actually have a description line saying what the command DOES.
>

(yeah, `man -K` -- versus `-k` for just the short descriptions -- ftw!)


> "zgrep -wl color /usr/share/man/man1/*.gz" worked though: looks like ls,
> top,
> grep, diff, and dmesg in toybox so far. (Plus less -R and watch -c but
> that's
> not an a decision about WHICH colors to output.) The troff man page says
> it has
> an option to _disable_ color output, but what does it do with color when
> it's
> not disabled?)
>
> I note that in dmesg you already enabled color with no --color to switch
> it on
> and no obvious way to switch it off except piping it through cat, so my
> current
> pondering on this topic has precedent. I may not know what's "right" but I
> tend
> to want the behavior to be CONSISTENT (and if at all possible have a common
> implementation), and right now it's not...
>

yeah, which probably shows that i'm usually on a dark background --- none
of those colors are problematic for me, and (perhaps more importantly) i
actually feel like i'm getting some value from that. similar to the git
diff colors (even if i'd like to have intra-line diff coloring!). whereas
the ls colors? i have never felt the need for that. (i also don't use -F,
for example, though i could understand having a trailing / on directories
better than i could understand colors.)

i guess the directory colors are so offensive because they're utterly
arbitrary. if you can reasonably map to traffic light colors (like diff or
dmesg), it's probably okay? else "get off my lawn!"?

(grep? not a fan, but it's not yet upset me enough to actually turn it off
on those machines that have it. but never helped me enough to turn it on on
those that don't.)


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220815/91973c95/attachment.htm>