Kamil Rytarowski <n...@gmx.com> 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, m...@netbsd.org 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
