Re: face at point

[Eli Zaretskii <eliz@is.elta.co.il>]

On 19 Nov 2002, Fredrik Staxeng wrote:

> >> 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
> 
> I was talking about faces generally, not about specificially 
> about tty faces.

Me too.  The process I described touched many standard faces, on both 
tty's and graphic displays.

> The default font-lock faces contain serveral 
> that has too low contrast

Some of them are intentional, but I suspect most aren't.  Please help us 
make them better by reporting the specific cases to gnu.emacs.bug.

> the GNUS default faces use italics.

This should be reported to the Gnus maintainers.  I don't think Gnus 
faces were changed at all, Emacs just uses whatever the Gnus maintainers 
defined.  This is also true in general for the optional packages that 
define their own cases, the only exception being (IIRC) Ediff.

> Are you saying that these would be considered bugs today, rather
> than "those complain about this are the people who are able 
> to change this"?

If the default definitions of a face make it unreadable, that's a bug 
that should be reported, IMHO.  If the default is readable but unpleasant 
or annoying, please report that as well, but in that case it's possible 
that it's a matter of personal taste.

> >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.
> 
> That was one possible explanation why one face might work on 
> black-on-white, but not black-on-white.

You mean "white-on-black", yes?

> When I look at a computer screen and compare the impression from
> the same face white-on-black versus black-on-white, I get the
> imression that white-on-black is heavier than white-on-black 
> one.

Are you suggesting that black-on-white faces use larger weight on 
displays that support this?  If so, how much heavier?

> >> 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).
> 
> Presently, it's obvious that default colors are picked from rgb.txt.
> Names like LightGoldenRod...  I am suggesting that the should be of the
> form '#xxyyzz' instead, where xx = 00, 33, 66, 99, cc, ff.

Assuming we are talking about tty's, why is this important?  On a tty, 
Emacs translates a color name into an equivalent of #xxyyzz using a 
built-in list (see tty-colors.el), so using names and #xxyyzz gives the 
same result.  The names of the default colors are chosen so that the 
result of their translation give what we consider to be a reasonably good 
and readable appearance; doing the same with RGB won't change anything.

> I had a look at the Lisp code in 21.2, and I didn't see any static
> mapping. The mapping seemed to be dynamic, considering only the
> color itself, and not the one is was supposed in contrast to.

Sorry, I don't understand the problem, as this description is too terse 
for me.  Could you please elaborate?

> >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
> >slightly differently on each text terminal.  This makes the job of
> >getting readable faces much harder.
> 
> Theoretically there is no standard, but in practice there is.
> Almost all people having colors on their tty are running:
> a) console mode on Linux/*BSD, in case they have the EGA colors, 
> b) or they are running in a xterm, which in fact tries to be use the 
>    same colors as EGA. Many people (including me) have changed those
>    to the six fully saturated colors.

AFAIK, Unix consoles use an SVGA nowadays, not an EGA.  SVGA has slightly 
different color definitions, IIRC.

Moreover, SVGA can be programmed at startup to use different palette 
colors.  Even more important, no two SVGAs (or EGAs, for that matter) 
have the same default colors.  Just put two consoles of two different 
vendors side by side and observe.

So text-mode colors _are_ different.  I've seen more than a single case 
where a color combination that looked very readable on my VGA was 
reported as barely readable on someone else's.

Enter xterm and its ilk: not only do these have different default 
definitions of the 16 colors (e.g., compare xterm with rxvt), but they 
are _configurable_ on the user level!  Even if we discard the 
unreasonable cases whereby someone defines "green" as #ffffff, there's 
still a very large range of reasonable definitions, and some people 
actually do this.

> >> Looking good is a much more ambitious goal. I'll settle for readable.
> >
> >That's our goal as well.
> 
> But the description "look good" keeps kreeping in when the issue is
> readability.

Well, that's because we would like to have both ;-)

Of course, readability is more important that "looking good", at least 
IMHO.

> And finally, looking at the default colors in e.g.
> font-lock, it's obvious to me that the Emacs maintainers don't really
> understand these issues. 

That remark doesn't really help.  For starters, it doesn't tell the 
maintainers how to do better.  And I already said that the current 
defaults were subject to prolonged discussions and several phases of 
improvements.  It would help much more to hear specific suggestions for 
improvement (these are better posted to emacs-devel@gnu.org).