On 16.02.2019 04:04, Valery Ushakov wrote:
> 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.
>
Audible bell can ship similar information such as color. I was just
going to mention it myself. If someone wants to use it to ring in some
cases in terminal, it's fine. I have nothing against it if someone would
make use of it.
If a terminal can support audible bells, screen blinks or other kind of
events that can be specified in LS_COLOR rules, assuming they are
sufficiently standardized. I'm open to handle them, but I'm afraid that
we are down to basic colors and font properties such as bold text.
I would personally enable audible bell for listing with ls(1) *.core
files as they keep floating over my file system partitions. This is why
I suggested to evaluate GNU style of coloring ls(1) as more flexible (it
allows file-name matching rules)
>
>>>> 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.
>
I have written it explicitly that I support disabled colors by default
and even disable them in existing programs unless enabled (with proposed
getenv("COLORTERM")).
Right now there is no option (except cherry-picking GNU/other tools) to
use them for those who want/need them.
Shortcoming of colors is more code complexity (more LOC).
>
> 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).
>
emacs has different environment of operation (and it is IDE, not shell
prompt even if shell can be hosted inside emacs).
We have sometimes similar readability issue in LLVM buildbot build logs
as it's difficult to spot where is the build/test/etc error. using
ctrl-f isn't enough in some cases and it's easier to download logs and
grep them manually. With colors it would much easier, but unfortunately
in the logs they are stripped down (or more precisely: not emitted).
> 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.
>
This is true that this is tuned in distribution/shells, typically with
aliases.
This is why I tried to keep phrasing that this is done by default in
majority of mainstream distributions, instead of claiming that this is a
property of GNU.
> -uwe
>
On 16.02.2019 04:04, John Nemeth wrote:
> Actually, it tells me absolutely nothing as I have no clue
> what the different colours mean (not to mention that colours
> disappear when output is logged). All I know is that some directories
> look like an "explosion in a paint factory" or "angry fruit salad".
> The colours convey absolutely no information to me. I need to use
> other information to figure out what the colours are trying to tell
> me. And, at that point, I might as well just be using the other
> information.
>
If you look for information what does the color tell you as something is
suspicious, it means that they served their exact purpose as it raised
your attention.
But it's has to be disabled by default. No doubts on this from myself.
Attachment:
signature.asc
Description: OpenPGP digital signature