Re: colorls in base

[Christian Groessler <chris%groessler.org@localhost>]

On 2/16/19 2:35 AM, Kamil Rytarowski wrote:
> On 16.02.2019 02:14, maya%netbsd.org@localhost wrote:
> > There's a topic on peace-keeping in a large project.
> >
> > There are two types of feedback:
> >
> > - "this change makes the code simpler and twice as fast" (it's
> >    objectively better)
> > - "I like colorful terminals" (my personal opinion)
> I object that this is just 'I like' case, I consider colors as an
> elementary feature.


Me not. Let's agree to disagree...


> It's more visible in code or text editors as they
> can show you whether the inserted program or config file is well formed
> or not. There were also programming languages using them (forthColor) as
> a part of syntax. In the ls(1) case it's much easier to spot that there
> is something wrong with a file (like a broken symlink).


Can you see this in colored ls? Then maybe "ls -F" should be enhanced to 
show this as well.


> The world has moved on, it's today not just color vs no-color, but
> truecolor vs ansicolor. For example vt.c was patched in the Linux kernel
> in 2014 (rev. cec5b2a97a11a) to handle 24bit color codes in environments
> (and they are rather far from fancy end-user environments).


Why not truecolor vs ansicolor vs monochrome. Different shades of gray?


This extensive color coding in the modern world is a bad thing to me. I 
never know whether my cable receiver is turned on or off, LED color 
changes from green (or yellow?) to red. I just don't see the difference. 
If they just would pick *really* different colors, like blue and red. 
But no, they pick colors I cannot distinguish.

And, yes, in daily live, I can see and distinguish traffic lights. The 
only important thing in this regard...

regards,
chris