From: "Eli Zaretskii" <eliz@is.elta.co.il>
Subject: Re: face at point
Date: Mon, 18 Nov 2002 20:56:26 +0300 [thread overview]
Message-ID: <3405-Mon18Nov2002205625+0200-eliz@is.elta.co.il> (raw)
In-Reply-To: <1mptt36lat.fsf@Tempo.Update.UU.SE> (message from Fredrik Staxeng on 18 Nov 2002 14:48:26 +0100)
> 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.
next prev parent reply other threads:[~2002-11-18 17:56 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-15 2:13 face at point John Hunter
2002-11-15 2:50 ` Jesper Harder
2002-11-15 3:30 ` John Hunter
2002-11-15 3:40 ` Jesper Harder
2002-11-15 10:24 ` Oliver Scholz
2002-11-15 13:37 ` Jesper Harder
2002-11-15 14:51 ` Jesper Harder
2002-11-15 16:58 ` Oliver Scholz
2002-11-16 18:49 ` Kai Großjohann
2002-11-15 4:24 ` Miles Bader
[not found] ` <mailman.1037335988.3983.help-gnu-emacs@gnu.org>
2002-11-15 14:21 ` Michael J Downes
2002-11-15 14:31 ` John Hunter
2002-11-17 22:40 ` Tim Cross
2002-11-17 23:00 ` Miles Bader
2002-11-18 5:54 ` Tim Cross
2002-11-18 8:52 ` Miles Bader
[not found] ` <mailman.1037610573.27378.help-gnu-emacs@gnu.org>
2002-11-18 13:48 ` Fredrik Staxeng
2002-11-18 17:23 ` Oliver Scholz
2002-11-18 18:16 ` Fredrik Staxeng
2002-11-18 17:56 ` Eli Zaretskii [this message]
[not found] ` <mailman.1037646827.31512.help-gnu-emacs@gnu.org>
2002-11-19 6:02 ` Fredrik Staxeng
2002-11-19 6:47 ` Eli Zaretskii
2002-11-19 9:20 ` Miles Bader
2002-11-19 20:24 ` Kai Großjohann
2002-11-18 22:06 ` Tim Cross
2002-11-18 22:36 ` Jesper Harder
2002-11-19 2:00 ` Miles Bader
2002-11-19 1:55 ` Miles Bader
2002-11-19 5:31 ` Eli Zaretskii
[not found] ` <mailman.1037671096.385.help-gnu-emacs@gnu.org>
2002-11-19 5:58 ` Tim Cross
2002-11-19 6:24 ` Eli Zaretskii
2002-11-19 6:24 ` Fredrik Staxeng
2002-11-19 6:56 ` Eli Zaretskii
2002-11-19 8:56 ` Miles Bader
[not found] ` <mailman.1037696237.22239.help-gnu-emacs@gnu.org>
2002-11-19 9:46 ` Fredrik Staxeng
[not found] <mailman.1037688495.14173.help-gnu-emacs@gnu.org>
2002-11-19 8:54 ` Fredrik Staxeng
2002-11-19 18:14 ` Eli Zaretskii
[not found] ` <mailman.1037733383.18353.help-gnu-emacs@gnu.org>
2002-11-20 13:37 ` Fredrik Staxeng
2002-11-20 16:13 ` Eli Zaretskii
[not found] ` <mailman.1037812462.4160.help-gnu-emacs@gnu.org>
2002-11-20 17:56 ` Fredrik Staxeng
[not found] <mailman.1037687132.614.help-gnu-emacs@gnu.org>
2002-11-19 22:16 ` Tim Cross
2002-11-20 5:47 ` Eli Zaretskii
2002-11-20 11:06 ` Oliver Scholz
2002-11-20 14:01 ` Stefan Monnier <foo@acm.com>
2002-11-20 16:00 ` Michael Slass
[not found] <mailman.1037771296.12946.help-gnu-emacs@gnu.org>
2002-11-20 7:34 ` Miles Bader
2002-11-20 7:39 ` Kai Großjohann
[not found] ` <mailman.1037777785.20916.help-gnu-emacs@gnu.org>
2002-11-20 11:10 ` Oliver Scholz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3405-Mon18Nov2002205625+0200-eliz@is.elta.co.il \
--to=eliz@is.elta.co.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).