Re: colorls in base

[uwe%stderr.spb.ru@localhost (Valery Ushakov)]

Kamil Rytarowski <n54%gmx.com@localhost> wrote:

> 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.

You are misrepresenting.  As I see it, Christian was not objecting to
adding colors to ls, but to your statement that you "consider colors
as an elementary feature" and the implication that more color support
is to be added and that it should be turned on by default, as
corroborated by your other replies to this thread.  Please, correct me
if my perception is wrong.

Your counter-example with the audio support should be rephrased (to
match) to e.g. changing shell's default prompt to contain audible
bell.  _That_ is how your argument comes across, at least to me.


>>> 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).

You conflate arguing in favor of colorization in general and arguing
in favor of enabling colorized output by default in standard utilities
and then you shrug the opponents off as obvious BARBARIANS that are
against PROGRESS.  This is disingenios.


PS: I mostly don't want colors in the output of utilities.  My emacs
is gaudy like you wouldn't belive.  Including colorization for e.g.
compilation-mode that is both colorized *and* searchable *and* has
next-error *and* is not limited by the size of the terminal
scrollback.  So your cool stories about manually scrolling back
through terminal output using color cues to find the error message do
not impress me much as an argument in favor of colorization by default
:).  (that also reminds me that netbsd src+xsrc build log has about
half a million lines of output).

Also note that gnu ls or grep do not do colorized output by default,
you have to explicitly enable it.  Most linux distributions seems to
eanble it by default in shell rc via aliases, but it's easy to turn
off with unalias -a.

-uwe