help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: face at point


From: Eli Zaretskii
Subject: Re: face at point
Date: Mon, 18 Nov 2002 20:56:26 +0300

> Newsgroups: gnu.emacs.help
> From: Fredrik Staxeng <fstx+u@update.uu.se>
> Date: 18 Nov 2002 14:48:26 +0100
> 
> Today I run using black text on white background. But I still find
> that many of the default faces are nearly unreadable.
> 
> >From the previous flaming over subject I have gotten the impression
> that the Emacs maintainers prefer to treat this as a user preference
> issue. 
> 
> If that has changed to something more reasonable, could you state the
> new policy?

You are being unfair to the Emacs maintainers.  This issue was never
treated unreasonably, much less dismissed as user preferences.  In
fact, the default definitions for many standard faces on a tty were
discussed, debated, changed, tested by many users and pretesters,
discussed again, changed again, etc, ad nauseum.  You can see a large
part of those discussions in the archives of the emacs-devel mailing
list.  What you see in the current code base is the result of this
long and meticulous process, not some random set of colors somebody
haphazardly pulled out of thin air.

Let me add that Miles in particular was part of this process and it is
due to his contributions that the current color definitions are better
than the original ones, introduced with Emacs 21.1.

> Is is something like "the default faces should be easily 
> readable for 95% of the users on 99% percent of the hardware/operating
> system combinations out there."?

AFAIK, the policy is that the faces should be readable on most
displays and in addition that the default definitions of a particular
face should be similar, as much as it's possible, across different
types of display.  The latter means that if a face has a greenish
color on X, we start with a green or cyan color on a tty, and only go
away of that if the result is either unreadable or in conflict with
another important face.

> A face with higher weight (% covered by foreground paint) needs less
> color contrast than one with lower weight.

Are we talking about a tty?  If so, you have only 8 colors to choose
from, on most tty types, so I don't see how could Emacs consider
shades that depend on a weight.

If we are talking about X, it sounds like you are suggesting a
mechanism to dynamically change the default faces as function of the
display and font parameters.  That might be a good idea; please
suggest it to emacs-devel@gnu.org.

> Also, it seems to me, that
> on CRT:s, bright colors bleed into less bright ones. This makes a
> white face on black background than the same black-on-white.

Sorry, I cannot parse these two sentences; please elaborate.

> Pick default colors from a defined color map, e.g. the Netscape cube.
> Define a static mapping from those 216 colors to the EGA colors
> that PC consoles support. Provide a color-restriction option to 
> Emacs so that maintainers can easily test the effect of the color
> limitation.

If I understand correctly what you are suggesting, this has been done
already (although some parts, like the color restricting option, only
exist in the CVS, not in the released versions).

Again, tty colors were subject to extensive scrutiny and iterative
improvements, so I would be hard pressed to believe that any simple
solutions were not tried.

Finally, the tty-color code supports character-mode displays that are
not based on EGA (nor VGA) devices (e.g., xterm), so using EGA colors
is not always the right thing to do.  In other words, "green" looks
slightly differently on each text terminal.  This makes the job of
getting readable faces much harder.

> Looking good is a much more ambitious goal. I'll settle for readable.

That's our goal as well.

> Is there a way to make a color from three RGB values?

Most color-related functions accept the standard X #RGB and rgb:R/G/B
notations.  This works on X and on tty's alike.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]