On 16.02.2019 03:03, Christian Groessler wrote: > 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... > Does it mean that people not interested in music can now prompt for removing audio support? If they are not interested in it they can move on and ignore it in their uses-cases. > >> 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. > Yes (GNU ls). Adding yet another magic bit in file properties misses the point. It's the case where colors are useful for such perception of console output and not replaceable with anything viable. > >> 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? > Shades of gray are not distinguishable. Font size changes (supported on some terminals and xray) would have similar issue.
Attachment:
signature.asc
Description: OpenPGP digital signature