On Tue 19 Feb 2019 at 21:49:20 -0500, Thor Lancelot Simon wrote:
> I am *not* opposed to highlighting when ls (or vi, or...) is outputting
> to a terminal. I *am* opposed to the use of hardwired colors as
> "highlights". That practice is discriminatory against the color-blind
> and also punishes
On 20.02.2019 03:49, Thor Lancelot Simon wrote:
> Use abstract properties for highlighting syntax all you like -- bold,
> reverse video, italic, underline, heck, make the text blink if you
> have to. Modern terminals let users map those to colors if they
> choose anyway.
>
Decoration and even au
On Fri, Feb 15, 2019 at 09:47:37PM +0100, Kamil Rytarowski wrote:
>
> Colors nowadays are industry standard and increase readability.
Your unqualified statement is objectively false.
How do you know that the user's terminal isn't using the same
color -- or all too close to it -- for background a
On Sun, Feb 17, 2019 at 09:43:11PM +0100, Marc Balmer wrote:
> New features schould be on by default, why else would we import them?
So when are we getting that Lua-enabled installer?
*whistles innocently*
--
David A. Holland
dholl...@netbsd.org
Martin Husemann wrote:
> On Sun, Feb 17, 2019 at 09:56:56PM +, Alexander Nasonov wrote:
> > New features should start from the installer ;-)
> >
> > IMO, the installer should offer two choices of colour and
> > the selected choice should become a default for other tools.
>
> I strongly object
It became a bikeshed about 15 replies in. 100 replies later, we're
pretty deep. I took a short break from reading this thread to port a
programming language to NetBSD and it's already merged upstream. I
wonder if I can do a second one before this thread is over, some people
mentioned liking Swift.
On Sun, Feb 17, 2019 at 09:56:56PM +, Alexander Nasonov wrote:
> New features should start from the installer ;-)
>
> IMO, the installer should offer two choices of colour and
> the selected choice should become a default for other tools.
I strongly object to adding non-essenital choices to t
On 17.02.2019 20:24, Jonathan A. Kollasch wrote:
> On Fri, Feb 15, 2019 at 04:08:37AM +, David Holland wrote:
>> On Fri, Feb 15, 2019 at 04:43:24AM +0100, Kamil Rytarowski wrote:
>> > I'm for adding colors...
>>
>> I kind of agree with jnemeth; but as long as it isn't on by default I
>> don't
This is getting OT...
On 2/17/19 11:18 PM, Christos Zoulas wrote:
On Feb 17, 2019, at 4:49 PM, John Nemeth wrote:
On Feb 17, 10:33am, Christos Zoulas wrote:
} On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote:
} | On 2/17/19 5:52 AM, John Nemeth wrote:
} | > } We resist also
> On Feb 17, 2019, at 4:49 PM, John Nemeth wrote:
>
> On Feb 17, 10:33am, Christos Zoulas wrote:
> } On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote:
> } | On 2/17/19 5:52 AM, John Nemeth wrote:
> } | > } We resist also personal taste but aesthetics is also important for
>
al...@yandex.ru (Alexander Nasonov) writes:
>Marc Balmer wrote:
>> New features schould be on by default, why else would we import them?
>New features should start from the installer ;-)
>IMO, the installer should offer two choices of colour and
>the selected choice should become a default for o
Marc Balmer wrote:
> New features schould be on by default, why else would we import them?
New features should start from the installer ;-)
IMO, the installer should offer two choices of colour and
the selected choice should become a default for other tools.
--
Alex
On 2/17/19 10:05 PM, David Holland wrote:
On Sun, Feb 17, 2019 at 07:57:52PM +, David Holland wrote:
> Why? Does every terminal window out there have the same background
> color?
So, just for shits and giggles, here's twenty xterm color pairs from
my master list of decently legible and r
On Feb 17, 10:33am, Christos Zoulas wrote:
} On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote:
} | On 2/17/19 5:52 AM, John Nemeth wrote:
} | > } We resist also personal taste but aesthetics is also important for
} | > } many/most(?) people. For the some reason probably nobody de
On Sun, Feb 17, 2019 at 07:57:52PM +, David Holland wrote:
> Why? Does every terminal window out there have the same background
> color?
So, just for shits and giggles, here's twenty xterm color pairs from
my master list of decently legible and reasonably nice-looking ones.
If anyone can pro
New features schould be on by default, why else would we import them?
> Am 17.02.2019 um 20:57 schrieb David Holland :
>
> On Sun, Feb 17, 2019 at 01:24:09PM -0600, Jonathan A. Kollasch wrote:
>>> Can we, however, please have colors that are not angry fruit salad? My
>>> understanding is that suf
On Sun, Feb 17, 2019 at 01:24:09PM -0600, Jonathan A. Kollasch wrote:
> > Can we, however, please have colors that are not angry fruit salad? My
> > understanding is that sufficiently recent xterm and terminfo is
> > capable of handling arbitrary rgb colors, so there's therefore no need
> > to
On Fri, Feb 15, 2019 at 04:08:37AM +, David Holland wrote:
> On Fri, Feb 15, 2019 at 04:43:24AM +0100, Kamil Rytarowski wrote:
> > I'm for adding colors...
>
> I kind of agree with jnemeth; but as long as it isn't on by default I
> don't care that much.
Seconded; as long as it's off by defau
On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote:
-- Subject: Re: colorls in base
| On 2/17/19 5:52 AM, John Nemeth wrote:
| > } We resist also personal taste but aesthetics is also important for
| > } many/most(?) people. For the some reason probably nobody delibe
On 2/17/19 2:19 AM, Kamil Rytarowski wrote:
Printing yellow
letters is readable on black background, but problematic on white.
And printing red letters is readable on white background, but
problematic on black.
On 2/17/19 5:52 AM, John Nemeth wrote:
} We resist also personal taste but aesthetics is also important for
} many/most(?) people. For the some reason probably nobody deliberately
} watches black-white TV and old valuable movies are now often painted.
Many people consider this to be ruinin
On 17.02.2019 05:52, John Nemeth wrote:
> On Feb 17, 12:52am, Kamil Rytarowski wrote:
> } On 16.02.2019 20:50, John Nemeth wrote:
> } > I'm not a no changenik. However, I think change needs to have
> } > demonstrated value. I do oppose change when it is done for the
> } > sake of change. To
On Feb 17, 12:52am, Kamil Rytarowski wrote:
} On 16.02.2019 20:50, John Nemeth wrote:
} > I'm not a no changenik. However, I think change needs to have
} > demonstrated value. I do oppose change when it is done for the
} > sake of change. To me, fluff is not demonstrated value, especially
}
On 17.02.2019 01:51, Paul Goyette wrote:
> On Sun, 17 Feb 2019, Joerg Sonnenberger wrote:
>
>> ... In this case, the color doesn't take anything away from
>> you. You are no worse off than before, e.g. you have to run additional
>> commands or long format to figure out what are subdirectories etc.
On Sun, 17 Feb 2019, Joerg Sonnenberger wrote:
... In this case, the color doesn't take anything away from
you. You are no worse off than before, e.g. you have to run additional
commands or long format to figure out what are subdirectories etc.
Not entirely true.
For those of use with red-gre
On 16.02.2019 20:50, John Nemeth wrote:
> I'm not a no changenik. However, I think change needs to have
> demonstrated value. I do oppose change when it is done for the
> sake of change. To me, fluff is not demonstrated value, especially
> when you consider our market segmen
That has been
On Fri, Feb 15, 2019 at 05:58:36PM +0100, Christian Groessler wrote:
> On 2/15/19 3:20 PM, Christos Zoulas wrote:
> > The kernel is already using green, and recently we added "autoconfiguration
> > error" to highlight errors. Shouldn't we (in addition) make those lines red?
>
>
> Please not. Red
On 16.02.2019 18:30, Robert Elz wrote:
> They haven't yet, but eventually will. Sometime, if this was added,
> someone will say "Why don't we enable colours from ls by default, just
> like all the other OS's do? We have the code already, all we need to do
> is turn it on." That's almost guarra
On Feb 17, 12:30am, Robert Elz wrote:
}
} Date:Sat, 16 Feb 2019 15:02:58 - (UTC)
} From:chris...@astron.com (Christos Zoulas)
} Message-ID:
}
} What I do replace from base (every time) is postfix (by sendmail).
} Somehow I doubt that a request to stick sendmail ba
On Feb 16, 3:02pm, Christos Zoulas wrote:
} In article <20190216102435.ga10...@grapefruit.pr0.tips>,
} Timo Buhrmester wrote:
} >> All I know is that some directories look like an "explosion in a
} >> paint factory" or "angry fruit salad".
} >I wonder why the die-hard monochrome users keep argui
On Feb 16, 12:42pm, Timo Buhrmester wrote:
}
} > Prettiness is the last thing that concerns me, cloaking information with
} > gleeful colorized flashlights and blinding me with candy colored dots is.
} Sorry, I wasn't aware how messed up cognition can be. Which color
} is the most blinding to you?
> On Feb 16, 2019, at 12:30 PM, Hauke Fath
> wrote:
>
> I remember you speaking up against replacing csh(1) with tcsh in base a few
> years ago. How about adding tcsh's complete facility to csh(1)? That is
> probably an order of magnitude in codesize compared to ls(1) vs.
> colo(u)rls, but I
At 15:02 Uhr + 16.02.2019, Christos Zoulas wrote:
>Yes, what I don't understand (because nobody has stated a technical
>reason other than 'fluff'),
... I guess that hurt. It wasn't meant to, sorry, just a tongue-in-cheek
handle to a serious point.
> why we shouldn't we have the feature in bas
At 19:47 Uhr + 15.02.2019, m...@netbsd.org wrote:
>I for one am quite fed up with how I have to replace around 30% of base
>to get a usable setup.
Yes. We've all been there, and I feel your pain.
> my set of substitutions are:
>
>- g95 -> gfortarn, because we don't default to modern fortran.
Date:Sat, 16 Feb 2019 15:02:58 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Yes, what I don't understand (because nobody has stated a technical
| reason other than 'fluff'), why we shouldn't we have the feature in base
| at all. Nobody pr
> Yes, what I don't understand (because nobody has stated a technical
> reason other than 'fluff'), why we shouldn't we have the feature in base
> at all. Nobody proposed to enable it by default.
Thank you!
I personally think it is unreasonable to oppose adding a
default-disabled feature like thi
On 2019-02-15 21:47, Kamil Rytarowski wrote:
> Colors nowadays are industry standard and increase readability.
I dislike colored ls with a passion simply because each time I use a
new Linux system, I can't see the very dark blue directory entries on
black background (in particular if there are o
In article <20190216102435.ga10...@grapefruit.pr0.tips>,
Timo Buhrmester wrote:
>> All I know is that some directories look like an "explosion in a
>> paint factory" or "angry fruit salad".
>I wonder why the die-hard monochrome users keep arguing from a
>"but it isn't pretty" point of view. It's
> To me it's the gloriously colorful that keep arguing that other people
> argue "but it isn't pretty".
Care to elaborate?
> Prettiness is the last thing that concerns me, cloaking information with
> gleeful colorized flashlights and blinding me
fstd.l...@gmail.com (Timo Buhrmester) writes:
>colors unconditionally, or by default even. I also have issues with
>the "I can't tell apart colors, so nobody may use colors" mindset.
You may use colors all day long, it's as simple as installing a color-ls
program.
Next time it's not about color
fstd.l...@gmail.com (Timo Buhrmester) writes:
>I wonder why the die-hard monochrome users keep arguing from a
>"but it isn't pretty" point of view. It's not supposed to be pretty,
>it's supposed to augment the information presented.
To me it's the gloriously colorful that keep arguing that other
> All I know is that some directories look like an "explosion in a
> paint factory" or "angry fruit salad".
I wonder why the die-hard monochrome users keep arguing from a
"but it isn't pretty" point of view. It's not supposed to be pretty,
it's supposed to augment the information presented.
> The
On Fri, 15 Feb 2019, m...@netbsd.org wrote:
> sorry, I came here with a bit of an axe to grind. probably weshould not
> make things hard to people who are color blind, when red/green color
> blindness is so common.
I just looked it up, this affects approximately 8% of european descent
males acco
On Sat, 16 Feb 2019, Christian Groessler wrote:
And, yes, in daily live, I can see and distinguish traffic lights. The only
important thing in this regard...
I actually have trouble at nighttime to tell the difference between the
green traffic lights and other "white" lights. I actually used
On 2/16/19 7:14 AM, Anders Magnusson wrote:
Don't know Debian, but at least Redhat:
[ragge@beta ~]$ ls -l /etc/profile.d/colorls.csh
-rw-r--r-- 1 root root 1741 30 jun 2016 /etc/profile.d/colorls.csh
Ok. I'm seeing colorls.sh and colorls.csh in /etc/profile.d on a Fedora
27 box.
My point
Christian Groessler wrote:
> On 2/15/19 10:28 PM, m...@netbsd.org wrote:
>> On Fri, Feb 15, 2019 at 10:17:55PM +0100, Christian Groessler wrote:
>>> On 2/15/19 8:15 PM, m...@netbsd.org wrote:
For the record I support the change. I don't think it's very hard not
to turn on colors. You ca
Den 2019-02-15 kl. 22:31, skrev Christian Groessler:
On 2/15/19 10:20 PM, Anders Magnusson wrote:
Den 2019-02-15 kl. 22:17, skrev Christian Groessler:
On 2/15/19 8:15 PM, m...@netbsd.org wrote:
For the record I support the change. I don't think it's very hard not
to turn on colors. You can tur
On Fri, Feb 15, 2019 at 07:11:59PM -0800, John Nemeth wrote:
> On Feb 16, 3:16am, Kamil Rytarowski 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-keepin
On 16.02.2019 04:04, Valery Ushakov wrote:
> Kamil Rytarowski 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 a
m...@netbsd.org writes:
> 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)
>
> Objecting to a diff like this caus
On 16/02/2019 03:11, John Nemeth wrote:
I often get difficult to read paint factory
explosions and basic things like "ifconfig" have disappeared (every
freaking unix-like system I've touched in the last 30 years has
had "ifconfig", but now a few NIHs are trying to make it go away).
One of my la
On Feb 16, 3:16am, Kamil Rytarowski 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:
} >>
On Feb 16, 2:35am, 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 lik
Kamil Rytarowski 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 ma
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 i
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 use
On 16.02.2019 03:16, Kamil Rytarowski wrote:
> Shades of gray are not distinguishable. Font size changes (supported on
> some terminals and xray) would have similar issue.
>
To be more precise (before someone will protest) shadow of gray can be
distinguishable in some contexts and circumstances,
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 f
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
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 tha
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)
Objecting to a diff like this causes friction. I like Rin, and I don't
wa
On 16.02.2019 01:34, Christian Groessler wrote:
> And, "COLORTERM" is not enough. What if you want different color schemes
> schemes for different programs? It's more to it.
>
COLORTERM contains two standard values truecolor and 24bit. At this
point I proposed to just respect whether it's define
On 2/16/19 1:08 AM, Kamil Rytarowski wrote:
On 16.02.2019 00:49, Paul Goyette wrote:
It's been solved already - it's in pkgsrc.
I find it a little bit overkill to replace ls with gls and in some cases
it doesn't work (gnu ps on NetBSD? color-vmstat?).
I am not objecting to implementing colo
On Sat, 16 Feb 2019, m...@netbsd.org wrote:
Add to ~/.Xresources:
! show red as green
*.color1: #D7005F
*.color9: #D7005F
xrdb -merge ~/.Xresources (I do this with ~/.xinitrc)
Blue or Cyan would actually be better than Green! :)
"Reverse-video" (or rv+bold) is actually the biggest attention
Add to ~/.Xresources:
! show red as green
*.color1: #D7005F
*.color9: #D7005F
xrdb -merge ~/.Xresources (I do this with ~/.xinitrc)
On 16.02.2019 00:49, Paul Goyette wrote:
> On Sat, 16 Feb 2019, Kamil Rytarowski wrote:
>
>> With colors we can easily scroll thousands of lines in a terminal
>> emulator and immediately catch where is the error message (red) within
>> a fraction of second.
>
> Not true. My eyes require LARGE am
On Fri, 15 Feb 2019 at 10:46, Manuel Bouyer wrote:
> On Fri, Feb 15, 2019 at 10:05:04AM -0800, Alistair Crooks wrote:
> > [...]
> >
> > (my motivation is that my eyes are not getting any better,
>
> nor do mine
>
> > and i need the
> > visual cues that coloring gives me. If anyone doubts it would
As a service to the community, I hereby present my colorls script:
/bin/ls -al $@ | awk '
function p(s, color) { printf("%c[0;%dm%s%c[0m\n", 27, color, s, 27); }
BEGIN { black = 30; red = 31; green = 32; yellow = 33; blue = 34; purple =
35; cyan = 36 ; gray = 37 }
/^dt/ { p($0, green); nex
On Sat, 16 Feb 2019, Kamil Rytarowski wrote:
With colors we can easily scroll thousands of lines in a terminal
emulator and immediately catch where is the error message (red) within
a fraction of second.
Not true. My eyes require LARGE amounts of color info, especially for
certain colors lik
On 15.02.2019 23:11, Christian Groessler wrote:
>
> Sorry, but that's a non-argument to me. I got by with compiler errors
> for many years by just running "cc ... files.c 2>&1 | less" and looking
> at the first few errors. To distinguish between warnings, search for
> "error:" when needed. And th
On 2/15/19 10:45 PM, m...@netbsd.org wrote:
Consider the problem of compilers emitting messages for bad code. You'll
have like 3 warnings and 2 errors, and possibly 2 page fulls of
messages.
You want to improve things, make it faster to find the problem, so you
would like the error to be more no
On Fri, Feb 15, 2019 at 10:51:05AM -0800, Alistair Crooks wrote:
> > Actually, colorized texts do things worse for me, because by highlingting
> > some thing it prevents me from seeing other important things.
> >
>
> Of course, but sane highlighting of things, rather than explosions in a
> paint f
On 2/15/19 10:28 PM, m...@netbsd.org wrote:
On Fri, Feb 15, 2019 at 10:17:55PM +0100, Christian Groessler wrote:
On 2/15/19 8:15 PM, m...@netbsd.org wrote:
For the record I support the change. I don't think it's very hard not
to turn on colors. You can turn them off even in linux.
"You can tu
Or you can:
- Get the best of all worlds, not have to change anything, and emit the
word "error:' in another color for interactive users.
Putting the output in a logfile (often with "| tee") and "grep
Error:" usually works for me. :)
+--+--+---
On Fri, Feb 15, 2019 at 02:20:05PM -, Christos Zoulas wrote:
>
> All this color discussion made me think:
>
> The kernel is already using green, and recently we added "autoconfiguration
> error" to highlight errors. Shouldn't we (in addition) make those lines red?
please no. I have autoconfi
On Fri, Feb 15, 2019 at 10:16:47PM +0100, Christian Groessler wrote:
> On 2/15/19 9:47 PM, Kamil Rytarowski wrote:
> > On 15.02.2019 17:58, Christian Groessler wrote:
> > > Please not. Red (esp. dark read) will be difficult to read for me. I'm
> > > color blind.
> > export TERM=vt100 (or similar)
>
On Fri, 15 Feb 2019, Christian Groessler wrote:
On 2/15/19 9:47 PM, Kamil Rytarowski wrote:
On 15.02.2019 17:58, Christian Groessler wrote:
Please not. Red (esp. dark read) will be difficult to read for me. I'm
color blind.
export TERM=vt100 (or similar)
Colors nowadays are industry standard
On 15.02.2019 22:16, Christian Groessler wrote:
> On 2/15/19 9:47 PM, Kamil Rytarowski wrote:
>> On 15.02.2019 17:58, Christian Groessler wrote:
>>> Please not. Red (esp. dark read) will be difficult to read for me. I'm
>>> color blind.
>> export TERM=vt100 (or similar)
>>
>> Colors nowadays are in
On 2/15/19 10:20 PM, Anders Magnusson wrote:
Den 2019-02-15 kl. 22:17, skrev Christian Groessler:
On 2/15/19 8:15 PM, m...@netbsd.org wrote:
For the record I support the change. I don't think it's very hard not
to turn on colors. You can turn them off even in linux.
"You can turn them off ev
On Fri, Feb 15, 2019 at 10:17:55PM +0100, Christian Groessler wrote:
> On 2/15/19 8:15 PM, m...@netbsd.org wrote:
> > For the record I support the change. I don't think it's very hard not
> > to turn on colors. You can turn them off even in linux.
>
>
> "You can turn them off even in linux."
>
>
On 2/15/19 8:35 PM, m...@netbsd.org wrote:
Adding to the previous:
- I will personally use it (especially if fish knows to automatically
use it)
What's the problem in installing "colorls" from pkgsrc? I'm typically
installing a bunch of packages after a fresh install of NetBSD, since
they
Den 2019-02-15 kl. 22:17, skrev Christian Groessler:
On 2/15/19 8:15 PM, m...@netbsd.org wrote:
For the record I support the change. I don't think it's very hard not
to turn on colors. You can turn them off even in linux.
"You can turn them off even in linux."
How do you do it?
rm /etc/prof
On 2/15/19 9:47 PM, Kamil Rytarowski wrote:
On 15.02.2019 17:58, Christian Groessler wrote:
Please not. Red (esp. dark read) will be difficult to read for me. I'm
color blind.
export TERM=vt100 (or similar)
Colors nowadays are industry standard and increase readability
"increase readability
On 2/15/19 8:15 PM, m...@netbsd.org wrote:
For the record I support the change. I don't think it's very hard not
to turn on colors. You can turn them off even in linux.
"You can turn them off even in linux."
How do you do it?
regards,
chris
> Am 15.02.2019 um 21:47 schrieb Kamil Rytarowski :
>
> On 15.02.2019 17:58, Christian Groessler wrote:
>> On 2/15/19 3:20 PM, Christos Zoulas wrote:
>>> The kernel is already using green, and recently we added
>>> "autoconfiguration
>>> error" to highlight errors. Shouldn't we (in addition) ma
On 15.02.2019 17:58, Christian Groessler wrote:
> On 2/15/19 3:20 PM, Christos Zoulas wrote:
>> The kernel is already using green, and recently we added
>> "autoconfiguration
>> error" to highlight errors. Shouldn't we (in addition) make those
>> lines red?
>
>
> Please not. Red (esp. dark read)
On Fri, Feb 15, 2019 at 08:04:13PM +0100, Hauke Fath wrote:
> At 18:29 Uhr + 15.02.2019, Christos Zoulas wrote:
> >>That's why I have to install XEmacs, tcsh and uucp from pkgsrc. Which is
> >>fine.
> >
> >So the question then becomes: "Is something that you presumably need,
> >since you use ev
Adding to the previous:
- I will personally use it (especially if fish knows to automatically
use it)
- I know several netbsd developers who either have variations of colorls
or use GNU ls purely for its support of color.
At 18:29 Uhr + 15.02.2019, Christos Zoulas wrote:
>>That's why I have to install XEmacs, tcsh and uucp from pkgsrc. Which is
>>fine.
>
>So the question then becomes: "Is something that you presumably need,
>since you use everyday 'fluff'?"
The way I see it, you _need_ a functionality (editor,
For the record I support the change. I don't think it's very hard not
to turn on colors. You can turn them off even in linux.
I think having ls -G is a bit redundant, but compatibility with either
one is probably worth it.
I don't expect netbsd will ever change its defaults unless forked, you
hav
On Fri, Feb 15, 2019 at 10:05:04AM -0800, Alistair Crooks wrote:
> [...]
>
> (my motivation is that my eyes are not getting any better,
nor do mine
> and i need the
> visual cues that coloring gives me. If anyone doubts it would work for
> them,
Actually, colorized texts do things worse for me,
In article ,
Hauke Fath wrote:
>At 11:46 Uhr -0500 15.02.2019, Christos Zoulas wrote:
>>| Please read it again - that is not what Rin said. In fact, he gave
>>| technical reasons.
>>
>>I am not happy with the interaction, not the decision.
>
>That's fine. I can understand that.
>
>>| As did I - "
At 13:58 Uhr + 15.02.2019, Christos Zoulas wrote:
>In article <2e0ff950-5f64-c807-1fc3-2d4b9e10b...@gmail.com>,
>Rin Okuyama wrote:
>>OK, I withdraw the proposal.
>>
>>Before pointed out by Kamil, I thought it useful to have compatible
>>with FreeBSD/OS X. But as he wrote, their style is diso
At 11:46 Uhr -0500 15.02.2019, Christos Zoulas wrote:
>| Please read it again - that is not what Rin said. In fact, he gave
>| technical reasons.
>
>I am not happy with the interaction, not the decision.
That's fine. I can understand that.
>| As did I - "relegate fluff to pkgsrc". ;)
>
>Is color
At 9:21 Uhr +0100 15.02.2019, Manuel Bouyer wrote:
>> } I know that we already have misc/colorls in pkgsrc. In the era of
>>
>> -1 we don't need this kind of annoying crap in base.
>
>seconded.
Same here.
Actually, this strikes me as exactly the kind of fluff that should not make
it into -base.
On 2/15/19 3:20 PM, Christos Zoulas wrote:
The kernel is already using green, and recently we added "autoconfiguration
error" to highlight errors. Shouldn't we (in addition) make those lines red?
Please not. Red (esp. dark read) will be difficult to read for me. I'm
color blind.
I'm also o
On Feb 15, 4:40pm, ha...@espresso.rhein-neckar.de (Hauke Fath) wrote:
-- Subject: Re: colorls in base
| At 13:58 Uhr + 15.02.2019, Christos Zoulas wrote:
| >In article <2e0ff950-5f64-c807-1fc3-2d4b9e10b...@gmail.com>,
| >Rin Okuyama wrote:
| >>OK, I withdraw the proposa
All this color discussion made me think:
The kernel is already using green, and recently we added "autoconfiguration
error" to highlight errors. Shouldn't we (in addition) make those lines red?
Someone mentioned that the gnu-color-ls style is better. I *think* that tcsh
does both (compatibly) f
In article <2e0ff950-5f64-c807-1fc3-2d4b9e10b...@gmail.com>,
Rin Okuyama wrote:
>OK, I withdraw the proposal.
>
>Before pointed out by Kamil, I thought it useful to have compatible
>with FreeBSD/OS X. But as he wrote, their style is disordered.
>
>If we redesign it, it would be something like rei
In article <20190215082158.gb...@antioche.eu.org>,
Manuel Bouyer wrote:
>On Thu, Feb 14, 2019 at 06:26:29PM -0800, John Nemeth wrote:
>> On Feb 15, 10:56am, Rin Okuyama wrote:
>> }
>> } I'd like to propose to introduction -G (colorized output) option
>> } to ls(1), which is compatible to FreeBSD
1 - 100 of 109 matches
Mail list logo
