Re: blue on black is unreadable
On Sun, Mar 26, 2000 at 12:54:39AM +0100, Wouter Hanegraaff wrote: Why does debian have to be different than the rest of the world in everything? Why do I get colors when I set TERM=xterm? there was already xterm-color and xterm-debian which could do colors. Other Linux distributions tend to default to a colour xterm, I thought. Right now, I have to set my TERM to xterm-mono on potato to avoid fruitsalads in a handful of programs I use very often (Mutt, dselect, vim). So why don't you just change your local settings to make xterm be mono? Ummm. `XTerm*ColorMode: no' seems like it'd do what you want. Please leave *personal* configuration to the *user* Indeed. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpghATCs1TAV.pgp Description: PGP signature
Re: blue on black is unreadable
On Sun, Mar 26, 2000 at 10:11:57AM +1000, Anthony Towns wrote: On Sun, Mar 26, 2000 at 12:54:39AM +0100, Wouter Hanegraaff wrote: Why does debian have to be different than the rest of the world in everything? Why do I get colors when I set TERM=xterm? there was already xterm-color and xterm-debian which could do colors. Other Linux distributions tend to default to a colour xterm, I thought. I thought slackware defaults to a non color xterm, and solaris too. And debian slink too, which is my main problem: Why is this setting changed between slink and potato?? So why don't you just change your local settings to make xterm be mono? Ummm. `XTerm*ColorMode: no' seems like it'd do what you want. That seems to work just fine. I wish I was aware of that resource a bit earlier... Wouter
Re: blue on black is unreadable
Wouter Hanegraaff wrote: Oh crap, you're right. I wasn't thinking on that one. Oh well, I guess somebody will have to find good colour combinations for every colour package. I can do that. Black on white. Proven to work perfectly for centuries. Or do you only read books with white letters on a black background, or all sorts of colors for differently styled text??? No, the difference is that computer monitors are fundamentally different media from books. Books work by reflecting surrounding light, whereas monitors emit the light themselves. I think having xterms with black on white to be comparable to reading a book in direct sunlight. It's not nice at all. I always read books in the shade. My xterms are all white on black. The exception is netscape which it black on light-grey, because for some reason true-type fonts look horrid the other way round. -- Martijn van Oosterhout [EMAIL PROTECTED]
Re: blue on black is unreadable
On Sun, Mar 26, 2000 at 12:54:39AM +0100, Wouter Hanegraaff wrote: Oh crap, you're right. I wasn't thinking on that one. Oh well, I guess somebody will have to find good colour combinations for every colour package. I can do that. Black on white. Proven to work perfectly for centuries. Or do you only read books with white letters on a black background, or all sorts of colors for differently styled text??? You betray profound ignorance. The pages of books (most of them, anyway) do not emit their own light. They are reflective only. CRT's generate light. If black-on-white xterms work fine for you, that's great. It's YOUR system and your choice. But your rationale betrays little understanding of the phsyiological/ergonomic issues involved. Is there a reason why xterm defaults to color xterm? In slink it does, on potato it's changed all of a sudden. The recent potato xterm packages change precious little from upstream behavior. You have a beef with it, take it up upstream. Why does debian have to be different than the rest of the world in everything? Why do I get colors when I set TERM=xterm? there was already xterm-color and xterm-debian which could do colors. You get colors when TERM=xterm because upstream says so. Any Linux distribution with a brain in its head uses XFree86 xterm for its version of xterm. nxterm is a piece of shit. If you want an X11R5-compatible xterm, use TERM=xterm-r5. Read /usr/share/doc/xterm/README.Debian and /usr/share/doc/xterm/xterm.faq.html for more information. Right now, I have to set my TERM to xterm-mono on potato to avoid fruitsalads in a handful of programs I use very often (Mutt, dselect, vim). That is very annoying, because it results in broken terminal settings when I login to *any* other system. Maybe I'm the only one who hates colors in xterms, but still. It should be possible to use xterms without colors in a normal way, and right now it isn't. It is, you just haven't bothered to read any documentation on the subject. Please leave *personal* configuration to the *user*, and leave the system configuration to some reasonable, _very_ conservative defaults. I agree with this statement but not the baggage you attach to it. As far as I'm concerned, conservative means upstream behavior. If upstream changes, I'll track those changes unless there is a very good reason not to (for instance, Debian policy). You desire to keep compatibility with a version of xterm that is ten years old is not a very good reason to accomodate you in the Debian defaults. Read that FAQ. Features have been added to xterm by Thomas Dickey, but the only changes that break compatibility have been bugfixes. I'm sorry if you've grown attached to some of X11R5's bugs. Please keep replies out of my personal mailbox. I read the lists. -- G. Branden Robinson| Convictions are more dangerous enemies Debian GNU/Linux | of truth than lies. [EMAIL PROTECTED] | -- Friedrich Nietzsche roger.ecn.purdue.edu/~branden/ | pgpjlhOWhE2Kx.pgp Description: PGP signature
Re: blue on black is unreadable
On Sun, Mar 26, 2000 at 04:07:11PM +0200, Wouter Hanegraaff wrote: So why don't you just change your local settings to make xterm be mono? Ummm. `XTerm*ColorMode: no' seems like it'd do what you want. That seems to work just fine. I wish I was aware of that resource a bit earlier... Perhaps if you read the manpage before whining and bitching to this mailing list, you'd spend less time being unhappy. colorMode (class ColorMode) Specifies whether or not recognition of ANSI (ISO 6429) color change escape sequences should be enabled. The default is ``true.'' -- G. Branden Robinson| Communism is just one step on the long Debian GNU/Linux | road from capitalism to capitalism. [EMAIL PROTECTED] | -- Russian saying roger.ecn.purdue.edu/~branden/ | pgpqJWcVx3zVE.pgp Description: PGP signature
Re: blue on black is unreadable
Date: 24 Mar 2000 11:43:38 +0100
From: Robert Bihlmeyer [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: blue on black is unreadable
Peter Cordes [EMAIL PROTECTED] writes:
Unless the darkish colours get used as alternate background colours, they
are wasted. There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours.
No it isn't. By acting against the ANSI standard, you will just move
the problem to other configurations: Users logged in from Non-Debian
machines will still see the unreadable combination. Just not using
black/blue is more prudent.
It's bad that we're stuck with this ...
Oh crap, you're right. I wasn't thinking on that one. Oh well, I guess
somebody will have to find good colour combinations for every colour
package. Some days it seems like there's always a reason why not to do
stuff that would otherwise be good :(
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black?
Because some people think it is the superior combination (it works
good on paper). Others think exactly the opposite.
With my colour mods to make ls output visible, could the default
change to be gray90 on black?
With this being highly religious a decision, I'd rather chicken out
and say: leave it be.
I'm going to go out on a limb and say that not many people actually like
black on white, or vice versa. Maybe the default should be
fg: black, bg: blanchedAlmond which works the same as black on white for
configuration of colours in programs, but which doesn't strain the eyes.
I guess the current system of having some stuff in the config file, but
commented out, is what we should continue to do. I think we could get away
with having blanchedAlmond background uncommented, though. I would really
like to see something other than the eyestrain inducing default. (bright
white is especially stressful unless your monitor has a very high refresh
rate, probably 80Hz or so, because it is so bright that the persistence of
vision effect isn't so strong, and the phosphors in the monitor probably
actually fade more noticeably. (This is pure speculation, but I know that
bright white looks more flickery on non-super-high rez monitors.)
--
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca)
The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: blue on black is unreadable
Oh crap, you're right. I wasn't thinking on that one. Oh well, I guess somebody will have to find good colour combinations for every colour package. I can do that. Black on white. Proven to work perfectly for centuries. Or do you only read books with white letters on a black background, or all sorts of colors for differently styled text??? Is there a reason why /etc/X11/Xresources/xterm defaults to black on white Is there any reason not to? But a more interesting question is the following: Is there a reason why xterm defaults to color xterm? In slink it does, on potato it's changed all of a sudden. Which is probably the reason I started this thread by filing a bug report against mutt's default colors. (see http://duckman.blub.net/~wouter/muttdefaults.png) I'm going to go out on a limb and say that not many people actually like black on white, or vice versa. Well, I do, as you know by now :) Maybe the default should be fg: black, bg: blanchedAlmond which works the same as black on white for configuration of colours in programs, but which doesn't strain the eyes. NO!!! Why does debian have to be different than the rest of the world in everything? Why do I get colors when I set TERM=xterm? there was already xterm-color and xterm-debian which could do colors. Right now, I have to set my TERM to xterm-mono on potato to avoid fruitsalads in a handful of programs I use very often (Mutt, dselect, vim). That is very annoying, because it results in broken terminal settings when I login to *any* other system. Maybe I'm the only one who hates colors in xterms, but still. It should be possible to use xterms without colors in a normal way, and right now it isn't. Please leave *personal* configuration to the *user*, and leave the system configuration to some reasonable, _very_ conservative defaults. Wouter. -- Wat voor een paperclip geldt, geldt in wezen ook voor een server. - Compaq over de nieuwste ProLiant servers
Re: blue on black is unreadable
Date: Thu, 23 Mar 2000 13:50:59 -0600
From: Steve Greenland [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: blue on black is unreadable
There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours.
No, you doen't use them. I use them a lot, to highlight urls and headers
in mutt, for example.
You're right that I don't use them all, but I do have colour highlighting
stuff turned on in mutt, and I use jed with syntax highlighting for C,
LaTeX, and HTML (in an xterm, not xjed). The thing is that I always have a
black background or else a colour that was already light
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black?
Because that's what xterms do (by default) on every other single X
implementation ever done? (Ok, that's probably an exageration...but not
completely misleading, either.)
Is that enough of a reason to not change it? Does it break any programs
specifically?
With my colour mods to make ls output visible, could the default
change to be gray90 on black? Most new users won't get around to
finding the xterm resources file for a long time, and I imagine they
would be happier with black bg xterms until they do.
I wouldn't. A lot of people I work with wouldn't. (Many would, of
course). I, for example, find it easier to read black text on light
backgrounds in xterms. My favorite is black on blanchedAlmond. I
don't, however, think that should be Debian's global default.
Hmm, that looks not bad. I notice that my adjusted bright-blue and blue
colours are still dark enough to be easily seen on the blanchedAlmond
background. However, symlinks, device files, and named pipes come out almost
invisible on that background. (I assume you have a nice DIRCOLORS setting
that fixes that, though.) I don't remember if the default on a fresh install
is to have ls use colours or not, but if it is then something should be done
so stuff isn't nearly invisible in an xterm. (If the default is to not use
colours, then leaving it the way it is is ok, I guess.)
(I wonder if the preference for light-on-dark vs dark-on-light depends
on ambient light conditions?)
I usually like to work in a relatively dark room. I think I'm nocturnal or
something (looks at clock... :(
We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
We do cater to them. We have window managers that support themes and
easy ways to change them.
Hrm, I've never used a heavyweight window manager with themes for more than
a few minutes. I think I noticed that the GNOME terminal lets you change
the colour scheme to fairly closely match the Linux console, which seems to
be where the ls default colours work best. (ls's default colours were
definitely chosen with a light-on-dark terminal in mind.)
We have a nice set of default colors. They are easy to modify (in the
xterm case, if you don't have the desire to mess with Xresources, -fg
and -bg work quite nicely). Are they they best possible defaults?
Probably not. But if you change them, probably for every person who you
made happier, there's another you've pissed off.
Why do so many people want to believe that their personal preferences
represent universal truth? I agree that demonstrably bad defaults
(dark-on-dark) should be changed. But the reality is that things like
color selection are such a personal-preference issue that *most* people
will eventually tweak them to their preference, and the best we can (and
should) do is use a *workable* default, and go on.
(If there is a 90% consensus that we change the xterm default to white
on black, and change the kernel definition (or whatever) of blue to
something lighter, then fine, do it. But I strongly believe that you
won't get anywhere near that much agreement.)
I'm one of those people who thought that my preference was universal truth
on this subject. I realize there are a lot of things that I like configured
differently from most people, and that there isn't any one set of settings
that is best for everyone. In the case of terminal colours, I thought most
people really did use black bg terminals, or at least dark something, like
blue. Also, real VT100s and VT220s have black bg screens with amber text.
There's a precedent for black bg terminals outside of X.
If it's not the case that almost everyone uses black bg terms, then I agree
that we shouldn't change it. In my experience, changing xterm colours is
one of the first things I after an install to localize the box to my tastes.
Other Unix users I know do similarly, I think.
I thought that most
Re: blue on black is unreadable
Peter Cordes [EMAIL PROTECTED] writes:
Unless the darkish colours get used as alternate background colours, they
are wasted. There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours.
No it isn't. By acting against the ANSI standard, you will just move
the problem to other configurations: Users logged in from Non-Debian
machines will still see the unreadable combination. Just not using
black/blue is more prudent.
It's bad that we're stuck with this ...
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black?
Because some people think it is the superior combination (it works
good on paper). Others think exactly the opposite.
With my colour mods to make ls output visible, could the default
change to be gray90 on black?
With this being highly religious a decision, I'd rather chicken out
and say: leave it be.
--
Robbe
Re: blue on black is unreadable
Peter Cordes [EMAIL PROTECTED] writes: In the case of terminal colours, I thought most people really did use black bg terminals, or at least dark something, like blue. Also, real VT100s and VT220s have black bg screens with amber text. There's a precedent for black bg terminals outside of X. Light (Amber, Green, Gray) on Black terminals probably made the most sense, back then. Most people will concur that a light background means too much eyestrain on CRT rates of 60 Hz or less. Low-end computers followed this trend (C64: amazingly readable lightblue/darkblue, Amiga: white/darkblue, IBM-PC: Gray,Green/Black) With the advent of powerful workstation monitors delivering 70 Hz or more, the most glaring problem of black/white became less and less important. I'll throw in another URL:http://www.dgp.toronto.edu/people/ematias/faq/S/S-9.html (Anwers from comp.human-factors to Which screen colors look best / produce the least eye strain?) -- Robbe
Re: blue on black is unreadable
On 24-Mar-00, 03:22 (CST), Peter Cordes [EMAIL PROTECTED] wrote: From: Steve Greenland [EMAIL PROTECTED] Because that's what xterms do (by default) on every other single X implementation ever done? (Ok, that's probably an exageration...but not completely misleading, either.) Is that enough of a reason to not change it? Does it break any programs specifically? It doesn't break programs, particularly, but it breaks configurations -- people whove changed only the foreground or background, or people who've set up other program's coloring to work on a black-on-white xterm. (I assume you have a nice DIRCOLORS setting that fixes that, though.) No, I think colored ls is the spawn of the devil. :-) (Actually I find colored ls a huge distraction, and all the information I need is provided by the '-F' option of ls) (I wonder if the preference for light-on-dark vs dark-on-light depends on ambient light conditions?) I usually like to work in a relatively dark room. I think I'm nocturnal or something (looks at clock... :( And I tend to work in well lit rooms, even at night -- so from our amazing sample of two, there is a correlation! [*big snip*] You've got a lot of valid points; I agree that black-on-white xterms do glare a little, although I've never had a real problem with them (when I use other people's systems, I hardly ever mess with the colors, even for a few days of work.) But the current defaults are defensible: it's the world-wide X standard default. Anything else amounts to personal preference and will promote a continuous stream of bug reports and complaints. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable
On Fri, Mar 24, 2000 at 03:29:07PM +0100, Robert Bihlmeyer wrote: With the advent of powerful workstation monitors delivering 70 Hz or more, the most glaring problem of black/white became less and less important. Even on 85Hz or even higher vertical frequencies, I find black-on-white XTerms quite hard to read. When you combine that with the fact that most people aren't using 640*480 resolution anymore, but (much) higher modes, but the font size in XTerm doesn't enlarge automagically with the screen resolution (why should it, one might ask), you get something barely usable. I may be an exception since I usually wear photo-sensible glasses to prevent eye-strain (and headaches), but I can't say I've seen many other `normal' people satisfied by the default XTerm appearance. BTW, FWIW, when in X, I use 1024*768*32*85, gray-on-black XTerm, font size 20. Although I still prefer the console :) -- enJoy -*/\*- don't even try to pronounce my first name
Re: blue on black is unreadable
On 24-Mar-00, 10:19 (CST), Steve Greenland [EMAIL PROTECTED] wrote: (I wonder if the preference for light-on-dark vs dark-on-light depends on ambient light conditions?) I usually like to work in a relatively dark room. I think I'm nocturnal or something (looks at clock... :( And I tend to work in well lit rooms, even at night -- so from our amazing sample of two, there is a correlation! And the link (http://www.dgp.toronto.edu/people/ematias/faq/S/S-9.html) that someone else provided said this: In an experiment with light- or dark-adapted subjects identifying target letters within a letter string from positive or negative displays, I also found interactions between adaptation level and display polarity (Fischer, 1992). Thus, the display of choice probably depends on your workplace illumination. (presumably with a sample count of more than 2) It also said this: Saturated blue should not be used for the presentation of fine detail, because the central part of the fovea is relatively insensitive to that color. For similar reasons, blue is an excellent background color. (Of course, that promotes light-on-dark) sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
On Thu, Mar 23, 2000 at 08:33:48AM +1100, Craig Sanders wrote: On Tue, Mar 21, 2000 at 04:23:31PM +0900, Junichi Uekawa wrote: garabik COLOR:1:cyan:black garabik COLOR:5:brightcyan:black The same can be said about the default ls colors. It shows directory names with blue on black. yep, i forgot to mention that until after i'd sent the message. blue on black is just a bad idea - too little contrast between fg bg to be readable. yellow on black is probably the best choice: good contrast and not not brigth. Very comfortable. But yellow on a white bg may not be so good. A+ -- Fabrice Gautier [EMAIL PROTECTED] I don't get no respect.
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
now that you have discovered the awful secret of debian, the secret cabal will have to take care of you. wait right where you are. there will be a knock on the door shortly. craig TINC
Re: blue on black is unreadable
Date: Wed, 22 Mar 2000 13:56:52 -0600
From: Steve Greenland [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: blue on black is unreadable
On 21-Mar-00, 20:06 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
The Linux text console is readable (barely), but xterm uses and even worse
colour for ANSI blue. (assuming black background). The fix for this
is to change the colour used by xterm for ANSI blue, instead of changing all
apps to use a different ANSI colour escape code.
That's a neat trick for xterms,
Thanks :)
but since even you admit that
blue-on-black is only barely readable on the text console, wouldn't it
be better to just not have default configurations use blue-on-black? (It
shouldn't be a matter of changing apps, only default configs.)
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
If you're setting up a default color scheme for an app, the basic rule
is to use light colored text on dark backgrounds, and dark colored text
on light backgrounds. The only other thing you need to know is that
neither red nor blue are light colors.
Unless the darkish colours get used as alternate background colours, they
are wasted. There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours. (jed uses blue for it's status line,
but yellow is still visible against the BLUE_COLOUR I suggested.)
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black? With my colour mods to make ls output visible,
could the default change to be gray90 on black? Most new users won't get
around to finding the xterm resources file for a long time, and I imagine
they would be happier with black bg xterms until they do. We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
--
#define X(x,y) x##y
DUPS Secretary ; http://is2.dal.ca/~dups/
Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca)
The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: blue on black is unreadable
On Wed, Mar 22, 2000 at 11:41:35PM -0400, Peter Cordes wrote:
Date: Wed, 22 Mar 2000 13:56:52 -0600
From: Steve Greenland [EMAIL PROTECTED]
To: debian-devel@lists.debian.org
Subject: Re: blue on black is unreadable
On 21-Mar-00, 20:06 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
The Linux text console is readable (barely), but xterm uses and even
worse
colour for ANSI blue. (assuming black background). The fix for this
is to change the colour used by xterm for ANSI blue, instead of changing
all
apps to use a different ANSI colour escape code.
That's a neat trick for xterms,
... but it makes default midnight commander setting in a xterm wacky
(lightgray and white on bright blue...).
Thanks :)
but since even you admit that
blue-on-black is only barely readable on the text console, wouldn't it
be better to just not have default configurations use blue-on-black? (It
shouldn't be a matter of changing apps, only default configs.)
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
actually, there is a program doing this (ctheme), it works in userspace,
modifying VGA palette. It is really great, has many themes included, and can
modify palette on per-console basis.
I am thinking of packaging it, when I get some spare time
If you're setting up a default color scheme for an app, the basic rule
is to use light colored text on dark backgrounds, and dark colored text
on light backgrounds. The only other thing you need to know is that
neither red nor blue are light colors.
Unless the darkish colours get used as alternate background colours, they
are wasted. There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours. (jed uses blue for it's status line,
but yellow is still visible against the BLUE_COLOUR I suggested.)
and midnight commander uses blue as background.
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black? With my colour mods to make ls output visible,
could the default change to be gray90 on black? Most new users won't get
around to finding the xterm resources file for a long time, and I imagine
they would be happier with black bg xterms until they do. We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
I personally like lightgray background and black foreground in xterm, because
this way small fonts are more readable... these preferences vary a lot
between users.
--
---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: blue on black is unreadable
On 22-Mar-00, 21:41 (CST), Peter Cordes [EMAIL PROTECTED] wrote:
Actually, I took another look at the console. The ANSI bright-blue used by
ls for directories is actually quite easy to see. The normal blue used by
lynx is not great, but readable. I'm sure there is a way to set the colours
the kernel uses somewhere, so doing this would be the best option.
No, because you then break all my settings that use normal (dark) blue
and red as background colors.
Unless the darkish colours get used as alternate background colours, they
are wasted.
They do.
There only are 16 colours, so deciding to never use 4
({dark ,}{blue,red}) of them seems like a bad idea. Brightening them up so
they look good on a black background is good, since hardly anything uses
dark-but-not-black background colours.
No, you doen't use them. I use them a lot, to highlight urls and headers
in mutt, for example.
Is there a reason why /etc/X11/Xresources/xterm defaults to black on white
instead of gray90 on black?
Because that's what xterms do (by default) on every other single X
implementation ever done? (Ok, that's probably an exageration...but not
completely misleading, either.)
With my colour mods to make ls output visible, could the default
change to be gray90 on black? Most new users won't get around to
finding the xterm resources file for a long time, and I imagine they
would be happier with black bg xterms until they do.
I wouldn't. A lot of people I work with wouldn't. (Many would, of
course). I, for example, find it easier to read black text on light
backgrounds in xterms. My favorite is black on blanchedAlmond. I
don't, however, think that should be Debian's global default.
(I wonder if the preference for light-on-dark vs dark-on-light depends
on ambient light conditions?)
We should cater
to users who don't know where you change everything by having a nice set of
default colours. This isn't like keymaps and stuff, since it only looks
different, and isn't nearly so hard to get used to.
We do cater to them. We have window managers that support themes and
easy ways to change them.
We have a nice set of default colors. They are easy to modify (in the
xterm case, if you don't have the desire to mess with Xresources, -fg
and -bg work quite nicely). Are they they best possible defaults?
Probably not. But if you change them, probably for every person who you
made happier, there's another you've pissed off.
Why do so many people want to believe that their personal preferences
represent universal truth? I agree that demonstrably bad defaults
(dark-on-dark) should be changed. But the reality is that things like
color selection are such a personal-preference issue that *most* people
will eventually tweak them to their preference, and the best we can (and
should) do is use a *workable* default, and go on.
(If there is a 90% consensus that we change the xterm default to white
on black, and change the kernel definition (or whatever) of blue to
something lighter, then fine, do it. But I strongly believe that you
won't get anywhere near that much agreement.)
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: blue on black is unreadable
On Tue, Mar 21, 2000 at 10:53:47PM -, [EMAIL PROTECTED] wrote: Date: Tue, 21 Mar 2000 17:21:22 +0200 From: Lauri Tischler [EMAIL PROTECTED] To: debian-devel@lists.debian.org Subject: Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors) Junichi Uekawa wrote: garabik lynx has the same problem. hyper links are blue on black, which makes it garabik very difficult to see where you are going. fixed with: garabik garabik COLOR:1:cyan:black garabik COLOR:5:brightcyan:black The same can be said about the default ls colors. It shows directory names with blue on black. These must be set up by some bug-eyed alien with colour-resolution going well into ultraviolet. :) The Linux text console is readable (barely), but xterm uses and even worse colour for ANSI blue. (assuming black background). The fix for this is to change the colour used by xterm for ANSI blue, instead of changing all apps to use a different ANSI colour escape code. xterm and (some) friends use the XTerm*colorn resource to say what X colour to use for ANSI colour n. This is documented in xterm(1). I like to use the following additions to /etc/X11/Xresources/xterm: ! local additions (PJC) /* blue that is used by color ls, and by lynx. this is brighter than default */ #define BLUE_COLOUR #ff XTerm*color4: BLUE_COLOUR XTerm*color12: BLUE_COLOUR XTerm*SimpleMenu.background:yellow XTerm*SimpleMenu*foreground:black XTerm*reverseWrap: true This makes ANSI blue nice and readable, in bold and non-bold. enjoy :) -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces! -- Plautus, 200 BCE
Re: blue on black is unreadable
On 21-Mar-00, 20:06 (CST), Peter Cordes [EMAIL PROTECTED] wrote: The Linux text console is readable (barely), but xterm uses and even worse colour for ANSI blue. (assuming black background). The fix for this is to change the colour used by xterm for ANSI blue, instead of changing all apps to use a different ANSI colour escape code. That's a neat trick for xterms, but since even you admit that blue-on-black is only barely readable on the text console, wouldn't it be better to just not have default configurations use blue-on-black? (It shouldn't be a matter of changing apps, only default configs.) If you're setting up a default color scheme for an app, the basic rule is to use light colored text on dark backgrounds, and dark colored text on light backgrounds. The only other thing you need to know is that neither red nor blue are light colors. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
On Tue, Mar 21, 2000 at 04:23:31PM +0900, Junichi Uekawa wrote: garabik COLOR:1:cyan:black garabik COLOR:5:brightcyan:black The same can be said about the default ls colors. It shows directory names with blue on black. yep, i forgot to mention that until after i'd sent the message. blue on black is just a bad idea - too little contrast between fg bg to be readable. craig -- craig sanders
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
On Tue, Mar 21, 2000 at 05:21:22PM +0200, Lauri Tischler wrote: The same can be said about the default ls colors. It shows directory names with blue on black. These must be set up by some bug-eyed alien with colour-resolution going well into ultraviolet. :) now that you have discovered the awful secret of debian, the secret cabal will have to take care of you. wait right where you are. there will be a knock on the door shortly. craig -- craig sanders
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
In Mon, 20 Mar 2000 09:40:53 +0100, de profundis Radovan Garabik [EMAIL PROTECTED] cum veritas scribat garabik lynx has the same problem. hyper links are blue on black, which makes it garabik very difficult to see where you are going. fixed with: garabik garabik COLOR:1:cyan:black garabik COLOR:5:brightcyan:black The same can be said about the default ls colors. It shows directory names with blue on black. -- dancer, a.k.a. Junichi Uekawa http://www.netfort.gr.jp/~dancer Dept. of Knowledge Engineering and Computer Science, Doshisha University. ... Long Live Free Software, LIBERTAS OMNI VINCIT.
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
Junichi Uekawa wrote: garabik lynx has the same problem. hyper links are blue on black, which makes it garabik very difficult to see where you are going. fixed with: garabik garabik COLOR:1:cyan:black garabik COLOR:5:brightcyan:black The same can be said about the default ls colors. It shows directory names with blue on black. These must be set up by some bug-eyed alien with colour-resolution going well into ultraviolet. :) -- Lauri Tischler, Network Admin Tel:+358-9-47846331* Mouse movement detected * Fax:+358-9-47846500* Reboot Windows to activate changes * Mobile: +358-40-5569010 EMail: [EMAIL PROTECTED]
Re: blue on black is unreadable (was Re: Bug#60753: mutt: /etc/Muttrc should not use colors)
On Mon, Mar 20, 2000 at 10:31:40AM +1100, Craig Sanders wrote: lynx has the same problem. hyper links are blue on black, which makes it very difficult to see where you are going. fixed with: COLOR:1:cyan:black COLOR:5:brightcyan:black I wonder who made up the default lynx colours... it is totally nauseating! the first think I do when installing new debian, I always reconfigure lynx to have saner colours (e.g. highlighted links are inverse) COLOR:0:lightgray:black COLOR:1:yellow:black COLOR:2:brightred:blue COLOR:3:green:black COLOR:4:magenta:black COLOR:5:blue:black COLOR:6:black:lightgray COLOR:7:magenta:cyan -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
