On 16.02.2019 03:36, Christian Groessler wrote: > On 2/16/19 3:16 AM, Kamil Rytarowski wrote: >> On 16.02.2019 03:03, Christian Groessler wrote: >>> 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. > > > I've never said that. And I also didn't want to remove the non-existing > color support. I'm just opposing to adding it (for the reasons I've > mentioned previously). > Didn't you notice my peace offer to not continue the discussion? > I haven't noted any technical rationale just expression 'I don't need it'. If so, just please ignore this feature. This thread does discuss existing (but still pending) support in the originally proposed patch. I would agree that there is no need to discuss non-existing code/patches. > >> >>>> 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. > > > IDK what you mean with "file properties" in this sentence. Of course, > the on-disk structures shouldn't be changed. But if "color ls" can > detect and and display a dangling symlink as such, a "non-color ls" > should be capable to do so as well. > By file properties I mean everything that can be printed with ls(1) in various modes, such as ls -l. Adding yet another option to the program and print yet another property of a file does not solve the requirement to quickly distinguish files in normal terminal operation (colors give this for free). Similarly with code editor we can catch syntax mistakes before using a compiler, even if everything is still doable with aid of other tools. Coloring ls(1) has the same purpose even if we can in the end catch the same things without colors (but it is less effective). > >> >>>> 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. >> > > Pah. Why are they not distinguishable for you? Do you have a problem > with your eyes (just kidding)? > To me yellow and green on the console are rather indistinguishable, as > are red and brown. And dark red is unreadable at all (with a black > backgound). > I've noted the rationale of my statement about the shades gray in another mail. > regards, > chris > And BTW. lack of colors in ls(1) as a STILL missing feature in NetBSD was discussed by developers (including more then a single one from core@) on at least a single BSD conference (and I just took part in few of them so far myself).
Attachment:
signature.asc
Description: OpenPGP digital signature