tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: colorls in base



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



Home | Main Index | Thread Index | Old Index