Re: face at point

Re: face at point

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> > All I really wanted to know was "Which is the best/most
> > appropriate/accepted way of distinguishing between emacs running on a
> > tty, in its own X frame and within an X term so that I can set my
> > colours accordingly. 
> 
> As I wrote earlier display-graphic-p and display-color-cells will let you 
> do that.

BTW, in the CVS version of emacs, I've written a new querying function
that's supposed to let you do more `result oriented queries' (though
whether it's actually enough, I'm not sure), somewhat clumsily called
`display-supports-face-attributes-p'.  Here's the help for it:

   display-supports-face-attributes-p is a compiled Lisp function in `faces'.
   (display-supports-face-attributes-p ATTRIBUTES &optional DISPLAY)

   Return non-nil if all the face attributes in ATTRIBUTES are supported.
   The optional argument DISPLAY can be a display name, a frame, or
   nil (meaning the selected frame's display)

   The definition of `supported' is somewhat heuristic, but basically means
   that a face containing all the attributes in ATTRIBUTES, when merged
   with the default face for display, can be represented in a way that's

    (1) different in appearance than the default face, and
    (2) `close in spirit' to what the attributes specify, if not exact.

   Point (2) implies that a `:weight black' attribute will be satisified by
   any display that can display bold, and a `:foreground "yellow"' as long
   as it can display a yellowish color, but `:slant italic' will _not_ be
   satisified by the tty display code's automatic substitution of a `dim'
   face for italic.display-supports-face-attributes-p is a compiled Lisp function in `faces'.
   (display-supports-face-attributes-p ATTRIBUTES &optional DISPLAY)

   Return non-nil if all the face attributes in ATTRIBUTES are supported.
   The optional argument DISPLAY can be a display name, a frame, or
   nil (meaning the selected frame's display)

   The definition of `supported' is somewhat heuristic, but basically means
   that a face containing all the attributes in ATTRIBUTES, when merged
   with the default face for display, can be represented in a way that's

    (1) different in appearance than the default face, and
    (2) `close in spirit' to what the attributes specify, if not exact.

   Point (2) implies that a `:weight black' attribute will be satisified by
   any display that can display bold, and a `:foreground "yellow"' as long
   as it can display a yellowish color, but `:slant italic' will _not_ be
   satisified by the tty display code's automatic substitution of a `dim'
   face for italic.

-Miles
-- 
Would you like fries with that?

Re: face at point

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On 20 Nov 2002, Tim Cross wrote:
>
>> All I really wanted to know was "Which is the best/most
>> appropriate/accepted way of distinguishing between emacs running on a
>> tty, in its own X frame and within an X term so that I can set my
>> colours accordingly. 
>
> As I wrote earlier display-graphic-p and display-color-cells will let you 
> do that.

Additionally, Tim might wish to use different colors on the Linux
console than in an xterm, perhaps because the bg color is dark in one
case and light in the other.  In that case, it might be useful to
check (getenv "TERM").  But only if display-color-cells doesn't help!

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: face at point

[Oliver Scholz]

Miles Bader <miles@lsi.nec.co.jp> writes:
[...]
> BTW, in the CVS version of emacs, I've written a new querying function
> that's supposed to let you do more `result oriented queries' (though
> whether it's actually enough, I'm not sure), somewhat clumsily called
> `display-supports-face-attributes-p'.  Here's the help for it:
[...]

Cool!

    Oliver
-- 
30 Brumaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: face at point

[Tim Cross]

Eli Zaretskii <eliz@is.elta.co.il> writes:

 
> > From my apropos searches, it seems there is quite
> > a few to choose from and can already see how to make a number of
> > alternatives work
> 
> If the ELisp manual in its node that describes display capabilities 
> doesn't explain how to do what you want, please submit a docs bug 
> report.  Thanks.
> 
Wow, this simple question I asked seems to have really gone off into
intersting tangents. Just to clarify a few things....

All I really wanted to know was "Which is the best/most
appropriate/accepted way of distinguishing between emacs running on a
tty, in its own X frame and within an X term so that I can set my
colours accordingly. 

The elisp manual is fine - I can certainly work out how to do this. In
fact, I can work out a number of ways of doing this and this is what
prompted my original question - I was wondering how others do it and
which is better. I've been using emacs for a few years, but am only
now getting into more "power usage" mode and teaching myself elisp
etc. I remembered seeing a thread some time ago here where a debate
broke out regarding why you should not use the window-system variable
to identify the type of system you are on and I was just after some
opinions on this.

With respect to the debate about choices of default colours - I'm
sorry, but I don't think there will ever be a resolution to this sort
of debate - there are too many variables involved, including
individual user taste, hardware, the workstation environment etc. I
think the best the maintainers can do is provide reasonable default
settings and clear documentation and ways of changing these defaults
(which has already been done). The great wonder of emacs is that the
user can customize all of this very easily, so long debates about the
default colours don't seem very productive (except in the academic
sense - always like a good debate). 

The one thing I'm very happy about and what I've always loved about X
and unix is that at least in most cases you can change default colour
settings and the changes are consistent. I am continually frustrated
in the Windows world where I define a colour scheme which I find
comfortable to work with only to find some applications only obey the
background settings for my scheme and ignore the foreground settings,
resulting in white on white or black on black or some other unreadable
combination!

Tim

Re: face at point

[Eli Zaretskii]

On 20 Nov 2002, Tim Cross wrote:

> All I really wanted to know was "Which is the best/most
> appropriate/accepted way of distinguishing between emacs running on a
> tty, in its own X frame and within an X term so that I can set my
> colours accordingly. 

As I wrote earlier display-graphic-p and display-color-cells will let you 
do that.

Re: face at point

[Oliver Scholz]

Tim Cross <tcross@nospam.une.edu.au> writes:
[...]
> All I really wanted to know was "Which is the best/most
> appropriate/accepted way of distinguishing between emacs running on a
> tty, in its own X frame and within an X term so that I can set my
> colours accordingly. 
[...]

The reason to use a check for specific display capabilities with the
`display-.*-p' functions is, that Emacs' capabilities on different
displays/operating systems may change in the future as well as the
operating systems/displays themselves. Even the distinction between a
tty and a graphical display may become more and more blurred. An xterm
may already display 256 colours, why not a future Linux console, too?
Why not real face attributes like bold and italic on a future console?
Emacs 20 did not display colours on a Linux console, for example, but
Emacs 21 does. Or the other way around: Emacs 21.2 does not display
images on MS Windows, although this is a graphical display. But Emacs
21.4 will do.

When you check for display capabilities as needed, you play safe. You
don't have to change your package or your .emacs according to the
display capabilities du jour. Therefore it is depreciated to check for
a specific display or operating system via `window-system' or some
such. In other words: there is no "appropriate/accepted way" to do
this.

    Oliver
-- 
30 Brumaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: face at point

[Stefan Monnier <foo@acm.com>]

>>>>> "os" == Oliver Scholz <alkibiades@gmx.de> writes:
> Why not real face attributes like bold and italic on a future console?

The future is today for those who use the Hurd.


        Stefan

Re: face at point

[Michael Slass]

"Stefan Monnier <foo@acm.com>" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

>>>>>> "os" == Oliver Scholz <alkibiades@gmx.de> writes:
>> Why not real face attributes like bold and italic on a future console?
>
>The future is today for those who use the Hurd.
>
>
>        Stefan

Both of them. ;)
-- 
Mike Slass

Re: face at point

[Fredrik Staxeng]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>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.

I apologize for bringing the X faces into this discussion. I think that 
the problems start there, but it is more useful to treat them as given 
when discussing tty face handling.

>> 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.

I will do that. But by intentional low contrast, surely you mean "lower
contrast used for deemphasizing", not "that text _should_ be hard to
read".

>> 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.

They don't want reopen that can of worms.

>> 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.

Readability is a continuum, and at what point a face becomes unreadble 
depends both on hardware, and on the user. Nobody can read 50% gray on
50% gray, some people can read 60% on 40%, and most can read 75% on 25%.
Also, it's possible, but mach harder to read such things as cyan
(#00ffff) on white.

I think default faces should use colors that, on most hardware,
result in high enough contrast to be easily readable by the vast
majority of users. I don't think that darkgreen on white does.

>> >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?

Of course.

>> 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?

No, that the same face in the same pixel rendering appear heavier
when white-on-black. It would say 20%, but you would have to 
test this on several people to get a good number for general use.

>> >> 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.

216 mappings are reasonable to test. It's easy to verify where the
boundaries between colors are, which color that get mapped to black,
and which get mapped to the primary. 

Of course, I was thinking about X colors when I wrote that. I have
just done some work to a program of mine to get it to work reasonably
on eight-bit pseudocolor displays, while working good on 24-bit
displays.

But on tty's, I don't think that you safely can use any colors
unless you know the background color. Perhaps ANSI color 1 (red)
is readable for everybody. Green (2) and blue (4) ar often 
actually colors that are too bright to usable on a white background.

If you assume eight fully saturated colors, and white background,
you can use red, green,  and blue as foregrounds, and yellow,
cyan and magenta as backgrounds. On a black background, you can
use all six as foreground colors. (The color names above actually
refer to the ANSI color numbers)

If you assume EGA colors, and black background, you can use many
more combinations. 

>> 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?

I can easily imagine cases that are reasonable contrast on X, but gets
mapped into very low contrast on tty:s.

>> >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.

Yes, but they are close enough that the same foreground/background
combinations can be used in most cases. The combinations that give
problems are mostly the ones that you should avoid for other reasons.

To give an example, with letters on blue background does not work 
with all blue colors. But it's imperative that this works on 
PC video cards, since Microsoft's installation programs uses that.

>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.

Yes, if skate on thin ice, you are bound to fall into the water sometimes.
That pair is probably too low contrast for some people even on your 
screen, but in anycase, it is best avoided in a default configuration.

>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.

I changed my colors because the EGA colors are not readable on a 
white background. That was a way of making Emacs color handling work
for me.

If you are not willing to assume anything about the colors corresponding
to the ANSI color numbers, then you can't use color at all. Conversely,
if you are using color, you are assuming some things. 

I think that EGA colors is reasonable assumption. I also think that
EGA/SVGA colors are compatible enough to give reasonable number of
widely usable combinations. 

>> >> 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 ;-)

That's OK when used in a positive sense. But as a response to "these
colors are unreadable", it's not good to say "that's a matter of user
preference".

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

If we have to choose between looking better on some hardware, versus
being readable on wider range of hardware, I vote for the second.

If we have to choose between looking better, versus being readable for
more users, I most definitely vote for the second. 

>> 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).

No, I know it doesn't help. It's just the frustration trying to explain
problems to people who personally can't see it. I try to propose solutions
that work for both them and me, and it is very frustrating to have 
these efforts dismissed with "you can change it if you don't like the
default". This is what is known as not getting it.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: face at point

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Fredrik Staxeng <fstx+u@update.uu.se>
> Date: 19 Nov 2002 09:54:48 +0100
> 
> I think default faces should use colors that, on most hardware,
> result in high enough contrast to be easily readable by the vast
> majority of users.

I agree, of course.

> I don't think that darkgreen on white does.

Well, there's no darkgreen on a tty.  Are you talking about X?

> >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.
> 
> 216 mappings are reasonable to test. It's easy to verify where the
> boundaries between colors are, which color that get mapped to black,
> and which get mapped to the primary. 

This has actually been done.  The purpose was to make sure that the
heuristic in tty-colors.el that decides when it is okay to map a
non-gray color to some shade of gray does its job reasonably well.

> But on tty's, I don't think that you safely can use any colors
> unless you know the background color.

Right; the default face definitions assume either black or white
background.  If a user changes her background to something else, she
will have to redefine many tty faces.

> If you assume eight fully saturated colors

[IIRC, the tty colors are not fully saturated, only their bright
varieties are.]

> If you are not willing to assume anything about the colors corresponding
> to the ANSI color numbers, then you can't use color at all. Conversely,
> if you are using color, you are assuming some things.

We are assuming that something called "red" is at least reddish in its
appearance.  The default colors were tested on many different systems
and to the best of my knowledge, when people complained some color to
be unreadable, the color was changed.

My point was that, color definitions on tty's being intrinsically
inexact, we should expect the results to be unpleasant or even barely
readable on some systems.  The goal is to minimize the number of such
systems, but it's a hard goal.

> If we have to choose between looking better on some hardware, versus
> being readable on wider range of hardware, I vote for the second.

Likewise.

> If we have to choose between looking better, versus being readable for
> more users, I most definitely vote for the second. 

Same here.

> No, I know it doesn't help. It's just the frustration trying to explain
> problems to people who personally can't see it. I try to propose solutions
> that work for both them and me, and it is very frustrating to have 
> these efforts dismissed with "you can change it if you don't like the
> default". This is what is known as not getting it.

I don't think there's such an attitude among the current maintainers,
except in those cases where it's hard to achieve agreement.

Re: face at point

[Fredrik Staxeng]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> Newsgroups: gnu.emacs.help
>> From: Fredrik Staxeng <fstx+u@update.uu.se>
>> Date: 19 Nov 2002 09:54:48 +0100
>> 
>> I think default faces should use colors that, on most hardware,
>> result in high enough contrast to be easily readable by the vast
>> majority of users.
>
>I agree, of course.

I have snipped the rest, since I think that we are agrreing on most 
points. I reread the initial complaint, and what he said was

> Well...I guess in theory that should work, but my experience has been
> that a number of faces are difficult to read when you use a dark
> (black) background - in particular, there are a number of faces which
> use variants of blue (navy, darker blue etc) and red or dark red which
> are difficult to read. I found this under both X and console.

I think that you might find those faces readable on your screen, or
you have changed them to something readable. The following discussion
was partly about perception, and partly about color support on ttys.

I think you need at least one of the following, but both would be
good.

- A way to emulate tty color when on X. That is, an Emacs maintainer 
  could just do M-x color-restrict to see if his faces get mapped
  reasonably.

- That Emacs consider both foreground and background pairs, and changes
  those that has been troublesome. E.g yellow:white -> red:white.
  This should be done at the ansi color number level.

This leaves the problem of deciding what the default background is on
ttys. I have no solution to this, except to ask the user.

- I also think that it would be good to have a color picker for X,
  that lets the user select from the 6x6x6 cube, and possibly modifying
  the color. This is a much better way of selecting colors than 
  reading rgb.txt and trial and error.

The reason for using that particular cube is that it then works well
for those people who still have 8-bit displays. Well not well,
but as good as it gets.

- If one really wants to go overboard with this, you would define some
  measure of color contrast, and then provide a way to set the minimum
  required contrast. If you set it to max, you get black-and-white.


-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: face at point

[Eli Zaretskii]

> Newsgroups: gnu.emacs.help
> From: Fredrik Staxeng <fstx+u@update.uu.se>
> Date: 20 Nov 2002 14:37:52 +0100
> 
> - A way to emulate tty color when on X. That is, an Emacs maintainer 
>   could just do M-x color-restrict to see if his faces get mapped
>   reasonably.

What I normally do is run "emacs -nw" from xterm.  The CVS code has a
way of forcing Emacs on a tty to use 8 colors even if the display
supports more (some versions of xterm support up to 256 colors).
This option only works in a non-windowed session, thus -nw.

> - That Emacs consider both foreground and background pairs, and changes
>   those that has been troublesome. E.g yellow:white -> red:white.

This might or might not be a good idea, I really don't know.  Suppose
the user really wants yellow on white--is it okay for Emacs to "know
better"?

For the default faces, this is already done manually: when the X
definition maps to something barely readable, like yellow on white, a
tty-specific definition is introduced with different colors.

> - I also think that it would be good to have a color picker for X,
>   that lets the user select from the 6x6x6 cube, and possibly modifying
>   the color. This is a much better way of selecting colors than 
>   reading rgb.txt and trial and error.

Emacs has `list-colors-display' and `list-faces-display' which I
think greatly simplify the process of customizing face colors.  Isn't
that a worthy equivalent of a color cube you envision?

Re: face at point

[Fredrik Staxeng]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> Newsgroups: gnu.emacs.help
>> From: Fredrik Staxeng <fstx+u@update.uu.se>
>> Date: 20 Nov 2002 14:37:52 +0100
>> 
>> - A way to emulate tty color when on X. That is, an Emacs maintainer 
>>   could just do M-x color-restrict to see if his faces get mapped
>>   reasonably.
>
>What I normally do is run "emacs -nw" from xterm.  The CVS code has a
>way of forcing Emacs on a tty to use 8 colors even if the display
>supports more (some versions of xterm support up to 256 colors).
>This option only works in a non-windowed session, thus -nw.

The easier it is, the more checking is likely to be done. Perhaps
the CVS way is easy enough that it will happen.

>> - That Emacs consider both foreground and background pairs, and changes
>>   those that has been troublesome. E.g yellow:white -> red:white.
>
>This might or might not be a good idea, I really don't know.  Suppose
>the user really wants yellow on white--is it okay for Emacs to "know
>better"?
>
>For the default faces, this is already done manually: when the X
>definition maps to something barely readable, like yellow on white, a
>tty-specific definition is introduced with different colors.

I was thinking that a tty user could add/remove pairs in the blacklist.
It does seem to be cumbersome to need to first change the the face, and
then change the blacklist.

>> - I also think that it would be good to have a color picker for X,
>>   that lets the user select from the 6x6x6 cube, and possibly modifying
>>   the color. This is a much better way of selecting colors than 
>>   reading rgb.txt and trial and error.
>
>Emacs has `list-colors-display' and `list-faces-display' which I
>think greatly simplify the process of customizing face colors.  Isn't
>that a worthy equivalent of a color cube you envision?

Except that 216 colors fit nicely in relatively small area. Look at xcmap
(not in the X distribution anymore it seems). 

Something like 

+--------------------------------------------- +
| +-----------+  +------------+ +-----------+  |
| |  list of  |  |            | |           |  |
| |  faces    |  | fg picker  | | bg picker |  |
| |           |  |            | |           |  |
| |           +  +------------+ +-----------+  |
| |           |  rgb fields      rgb fields
| +-----------+  fields for other attributes   |
+----------------------------------------------+

If you put this in one window, and have your C code in the other window,
and any changes you do apply immediately, selecting a set of good faces
would take about two minutes, _including_ learning how to do it. 
Have _one_ save button, and _one_ undo button that reverts to the saved
settings.

Oh, the face names should be rendered in the face.

For extra points, when the cursor is in the C buffer, select the 
corresponding face in the face buffer. 

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

face at point

[John Hunter]

[ I recently inadvertently posted this to g.e.gnus, but it really
belongs here.  Sorry for the crosspost ]

I don't really understand how to identify what faces are in use in a
given buffer.

I use color-theme (gnome2) which works fine under X but when I am
using font locking in emacs 21 in an xterm, I occasionally run into
problems.

Case in point: In gnus article mode, the face of quoted messages (the
cited text from previous posts that the article is following-up to) is
dark blue and hard to read against my black background xterm.

I would like to know which face I need to set so that the color is
more to my liking.  I tried apropos to see if there was a
gnus-article-cited-face or something like that, but didn't find it.
What would be really helpful, is if I could execute some function and
see what variable (symbol?) controlled the face at point.  Then I
could apply a mode-hook to set that face to my heart's desires.

Ie, how do I find out what face is responsible for a given segment of
text in a given mode?

John Hunter

Oort Gnus v0.05
GNU Emacs 21.2.1

Re: face at point

[Jesper Harder]

John Hunter <jdhunter@nitace.bsd.uchicago.edu> writes:

> I would like to know which face I need to set so that the color is
> more to my liking.

`M-x list-text-properties-at'

> I tried apropos to see if there was a gnus-article-cited-face or
> something like that, but didn't find it.

It's `gnus-cite-face-1'.  You could have used `M-x list-faces-display'
or maybe `M-x customize-face' to find it.

Re: face at point

[John Hunter]

>>>>> "Jesper" == Jesper Harder <harder@myrealbox.com> writes:

Many thanks.

    Jesper> `M-x list-text-properties-at'

This returned None when executed on the text in question/

    >> I tried apropos to see if there was a gnus-article-cited-face
    >> or something like that, but didn't find it.

    Jesper> It's `gnus-cite-face-1'.  You could have used `M-x
    Jesper> list-faces-display' or maybe `M-x customize-face' to find
    Jesper> it.

M-x list-faces-display - this returned so many choices that it was not
                         clear which face was the one of interest.

M-x customize-face     - this worked as advertised.

Thanks again,
John Hunter 

Re: face at point

[Jesper Harder]

John Hunter <jdhunter@nitace.bsd.uchicago.edu> writes:

>>>>>> "Jesper" == Jesper Harder <harder@myrealbox.com> writes:
>
> Many thanks.
>
>     Jesper> `M-x list-text-properties-at'
>
> This returned None when executed on the text in question/

Hmm, you're right ... strange.  It does work if you place point in
e.g. the message headers.

Re: face at point

[Oliver Scholz]

Jesper Harder <harder@myrealbox.com> writes:

> John Hunter <jdhunter@nitace.bsd.uchicago.edu> writes:
>
>>>>>>> "Jesper" == Jesper Harder <harder@myrealbox.com> writes:
>>
>> Many thanks.
>>
>>     Jesper> `M-x list-text-properties-at'
>>
>> This returned None when executed on the text in question/
>
> Hmm, you're right ... strange.  It does work if you place point in
> e.g. the message headers.

IIRC the gnus-cite-face-[0-9]+ are put on overlays in the article
buffer. `list-text-properties-at' does not list properties in
overlays.

    Oliver
-- 
25 Brumaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: face at point

[Jesper Harder]

Oliver Scholz <alkibiades@gmx.de> writes:

> IIRC the gnus-cite-face-[0-9]+ are put on overlays in the article
> buffer. `list-text-properties-at' does not list properties in
> overlays.

So, how do you find about properties in overlays interactively?

Re: face at point

[Jesper Harder]

Jesper Harder <harder@myrealbox.com> writes:

> So, how do you find about properties in overlays interactively?

Forget the question :-) Miles's function does it nicely.

Re: face at point

[Oliver Scholz]

Jesper Harder <harder@myrealbox.com> writes:

> Jesper Harder <harder@myrealbox.com> writes:
>
>> So, how do you find about properties in overlays interactively?
>
> Forget the question :-) Miles's function does it nicely.

Besides that, in the CVS version `C-u C-x =' does list text
properties, too -- properties in overlays included.

    Oliver
-- 
25 Brumaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: face at point

[Kai Großjohann]

John Hunter <jdhunter@nitace.bsd.uchicago.edu> writes:

> M-x list-faces-display - this returned so many choices that it was not
>                          clear which face was the one of interest.

Even though there are a lot of faces, having both the appearance and
the name helps a lot, IMHO.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: face at point

[Miles Bader]

John Hunter <jdhunter@nitace.bsd.uchicago.edu> writes:
> Ie, how do I find out what face is responsible for a given segment of
> text in a given mode?

(defun what-face (pos)
  (interactive "d")
  (let ((face (or (get-char-property (point) 'read-face-name)
                  (get-char-property (point) 'face))))
    (if face (message "Face: %s" face) (message "No face at %d" pos))))

-Miles
-- 
97% of everything is grunge

Re: face at point

[Michael J Downes]

Miles Bader <miles@lsi.nec.co.jp> writes:

> (defun what-face (pos)
>   (interactive "d")
>   (let ((face (or (get-char-property (point) 'read-face-name)
>                   (get-char-property (point) 'face))))
>     (if face (message "Face: %s" face) (message "No face at %d" pos))))

? I'm curious: How/who/when/why does a property 'read-face-name
ever get set?

The Emacs Lisp reference manual (2.8 for 21.2) has no index entry
for it:

  "No `read-face-name' in index"

There is a function for it in faces.el, but the function seems to be for
interactively reading a face name from the user, and I didn't see
anything in the code that would make a text property out of it.

Grepping in share/emacs/21.2/lisp/*.el doesn't seem to turn up anything
more enlightening either.

Re: face at point

[John Hunter]

>>>>> "Miles" == Miles Bader <miles@lsi.nec.co.jp> writes:

    Miles> (defun what-face (pos)
    Miles>   (interactive "d")
    Miles>   (let ((face (or (get-char-property (point) 'read-face-name)
    Miles>                   (get-char-property (point) 'face))))
    Miles>     (if face (message "Face: %s" face) (message "No face at %d" pos))))

This is perfect.  Thanks.

John Hunter

Re: face at point

[Tim Cross]

John Hunter <jdhunter@nitace.bsd.uchicago.edu> writes:

> [ I recently inadvertently posted this to g.e.gnus, but it really
> belongs here.  Sorry for the crosspost ]
> 
> I don't really understand how to identify what faces are in use in a
> given buffer.
> 

I find the following two functions very useful

,----[ C-h f list-colors-display RET ]
| list-colors-display is an interactive compiled Lisp function in `facemenu'.
| (list-colors-display &optional LIST)
| 
| Display names of defined colors, and show what they look like.
| If the optional argument LIST is non-nil, it should be a list of
| colors to display.  Otherwise, this command computes a list
| of colors that the current display can handle.
`----

and

,----[ C-h f list-text-properties-at RET ]
| list-text-properties-at is an interactive compiled Lisp function in `facemenu'.
| (list-text-properties-at P)
| 
| Pop up a buffer listing text-properties at LOCATION.
`----

As I also find many of the "default colours don't work well with a
dark background, I usually start my customization of emacs colours by
setting the default foreground/background and then using
list-colors-display to see the values for all loaded faces and setting
those which are difficult to read. If I find there is still a face in
some mode which is difficult to read I put the cursor on a bit of the
text and use list-text-properties-at-point to identify which face i
need to set.

Tim

Re: face at point

[Miles Bader]

Tim Cross <tcross@nospam.une.edu.au> writes:
> As I also find many of the "default colours don't work well with a
> dark background, I usually start my customization of emacs colours by
> setting the default foreground/background and then using

Note that emacs explicitly knows about this issue and maintains separate
dark-background defaults for many faces, so any default face that's not
readable on a dark background is a bug (of course in some cases it's
just a bad decision), so please report if you can.

If you're using emacs in a terminal, then it's possible that emacs is
confused about what sort of background it has (as there's no way to
query the terminal for this info, emacs has to guess), and is using the
wrong set of default faces; you can customize `frame-background-mode' to
force the issue.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: face at point

[Tim Cross]

Miles Bader <miles@gnu.org> writes:

> Tim Cross <tcross@nospam.une.edu.au> writes:
> Note that emacs explicitly knows about this issue and maintains separate
> dark-background defaults for many faces, so any default face that's not
> readable on a dark background is a bug (of course in some cases it's
> just a bad decision), so please report if you can.
> 
> If you're using emacs in a terminal, then it's possible that emacs is
> confused about what sort of background it has (as there's no way to
> query the terminal for this info, emacs has to guess), and is using the
> wrong set of default faces; you can customize `frame-background-mode' to
> force the issue.
> 

Well...I guess in theory that should work, but my experience has been
that a number of faces are difficult to read when you use a dark
(black) background - in particular, there are a number of faces which
use variants of blue (navy, darker blue etc) and red or dark red which
are difficult to read. I found this under both X and console.

I'm not sure there is a lot which can be done here though - there are
quite a few different faces and many of them are not very good with a
dark backgroun, so I think the choice for default dark background face
foreground colours are limited.

I did find under the console, some colours just didn't show up right,
but expect thats a result of the limited colours available under the
console. For example, yellow without the bold attribute shows up as
dark orange on my console and only looks yellow if the weight is set
to bold - I figure this is probably either something to do with either
the video card you have or it is the only way you can have a different
in "yellow" between normal and bold. Note that other console apps like
colour ls show yellow in the same way yellow bold is shown under
emacs. 

On another point, what is the "correct" way to determine when you are
working under X and when you are working under a consle terminal.
remember seeing some thread in one of the groups which recommended not
use the window-system variable (can't remember why). For my setup I'm
using the function device-type e.g.

(if (eq device-type 'tty)
   ;;;do tty color settings
 ;; do x color settings)

To make the changes, I use the set-face-attribute function. 

Anyway, was just wondering if this is a good/optimal approach or there
is a better alternative (it seems to be working fine for me at
present). 

Tim

Re: face at point

[Miles Bader]

Tim Cross <tcross@nospam.une.edu.au> writes:
> > Note that emacs explicitly knows about this issue and maintains separate
> > dark-background defaults for many faces, so any default face that's not
> > readable on a dark background is a bug, so please report if you can.
> 
> Well...I guess in theory that should work, but my experience has been
> that a number of faces are difficult to read when you use a dark
> (black) background - in particular, there are a number of faces which
> use variants of blue (navy, darker blue etc) and red or dark red which
> are difficult to read. I found this under both X and console.

Then they are broken; please report them as bugs.  I use a dark
background myself, and fix anything I see, but of course I don't use
every feature in emacs.

> I'm not sure there is a lot which can be done here though - there are
> quite a few different faces and many of them are not very good with a
> dark backgroun, so I think the choice for default dark background face
> foreground colours are limited.

Um, why does that matter?  If the set of foreground colors that contrast
well is limited, then the foreground colors should be chosen from that
set.  Of course, in some cases, the right choice is to set both the face
background _and_ foreground.

> I did find under the console, some colours just didn't show up right,
> but expect thats a result of the limited colours available under the
> console.

Yes, this is a common problem, and hard to solve perfectly.

However, emacs _does_ attempt to deal with it, and in some cases uses
different default faces for terminals [the console being a terminal],
if same face just can't be made to look good on both window-systems and
terminals.

> On another point, what is the "correct" way to determine when you are
> working under X and when you are working under a consle terminal.

Look at the functions beginning with `display-', e.g.,
`display-graphic-p', `display-color-p', or `display-multi-font-p'.

They are in the elisp manual in the node `(elisp)Display Feature Testing'.

> remember seeing some thread in one of the groups which recommended not
> use the window-system variable (can't remember why).  For my setup I'm
> using the function device-type e.g.

My emacs has no such function.

Are you perchance using xemacs?  If so, I think much of what I said
above may not apply.  In particular, I was under the impression that
xemacs had far less sophisticated handling of tty faces.

[Your email headers say `Emacs 21.2' though, so I'm not sure what to think...]

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: face at point

[Fredrik Staxeng]

Miles Bader <miles@lsi.nec.co.jp> writes:

>Tim Cross <tcross@nospam.une.edu.au> writes:
>> > Note that emacs explicitly knows about this issue and maintains separate
>> > dark-background defaults for many faces, so any default face that's not
>> > readable on a dark background is a bug, so please report if you can.
>> 
>> Well...I guess in theory that should work, but my experience has been
>> that a number of faces are difficult to read when you use a dark
>> (black) background - in particular, there are a number of faces which
>> use variants of blue (navy, darker blue etc) and red or dark red which
>> are difficult to read. I found this under both X and console.
>
>Then they are broken; please report them as bugs.  I use a dark
>background myself, and fix anything I see, but of course I don't use
>every feature in emacs.

I am old enough to have a preference for amber phosphor over green.
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? 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."?

Otherwise there seems to be little point in reporting unreadable
faces as bugs. Obviously the author could read the face on his
screen.

>> I'm not sure there is a lot which can be done here though - there are
>> quite a few different faces and many of them are not very good with a
>> dark backgroun, so I think the choice for default dark background face
>> foreground colours are limited.
>
>Um, why does that matter?  If the set of foreground colors that contrast
>well is limited, then the foreground colors should be chosen from that
>set.  Of course, in some cases, the right choice is to set both the face
>background _and_ foreground.


A face with higher weight (% covered by foreground paint) needs less
color contrast than one with lower weight. 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.

One person I know prefer 1280x1024 to 1600x1280 because the higher 
resolution makes his fonts to thin, even when he chooses a bigger
font to make the apparent size the same.

>> I did find under the console, some colours just didn't show up right,
>> but expect thats a result of the limited colours available under the
>> console.
>
>Yes, this is a common problem, and hard to solve perfectly.

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.

No, it's not perfect. Perfect color support takes 24 bits. There 
is no way around that. But I think the above would be good enough.

>However, emacs _does_ attempt to deal with it, and in some cases uses
>different default faces for terminals [the console being a terminal],
>if same face just can't be made to look good on both window-systems and
>terminals.

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

By the way, I found a way to get the rgb components from a color in Emacs.
Is there a way to make a color from three RGB values? The idea is to
take the color apart, scale the components to make the color darker,
and then put a set-face-forground in my .emacs.

Since it this time of the year, let me add a wish for a lisp hook
to be run when a face is realized, where I could put a function
that simply changes things to the way I want them.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: face at point

[Oliver Scholz]

Fredrik Staxeng <fstx+u@update.uu.se> writes:
[...]
> By the way, I found a way to get the rgb components from a color in Emacs.
> Is there a way to make a color from three RGB values? The idea is to
> take the color apart, scale the components to make the color darker,
> and then put a set-face-forground in my .emacs.

;;                              R G B 
(set-face-foreground 'default "#234ff3")


    Oliver
-- 
28 Brumaire an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: face at point

[Fredrik Staxeng]

Oliver Scholz <alkibiades@gmx.de> writes:

>Fredrik Staxeng <fstx+u@update.uu.se> writes:
>[...]
>> By the way, I found a way to get the rgb components from a color in Emacs.
>> Is there a way to make a color from three RGB values? The idea is to
>> take the color apart, scale the components to make the color darker,
>> and then put a set-face-forground in my .emacs.
>
>;;                              R G B 
>(set-face-foreground 'default "#234ff3")

Of course. And the string can be done with 
        (format "#%02x%02x%02x" 35 79 243)

Thanks for taking the time to point out the obvious to me.

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: face at point

[Eli Zaretskii]

> 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.

Re: face at point

[Fredrik Staxeng]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> 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

I was talking about faces generally, not about specificially 
about tty faces. The default font-lock faces contain serveral 
that has too low contrast, the GNUS default faces use italics.
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"?

>> 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.

That was one possible explanation why one face might work on 
black-on-white, but not black-on-white.

>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.

I am explaining to you and Miles how _humans_ work, in this case
human perception of letter forms rendered on a computer screen.

>> 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.

I missed an adjective there. But for Gutenberg, letters
got heavier in printing because ink bled into the white areas.
When technology changed in the seventies, the printing industry
had to make the faces heavier to compensate for the less
bleeding of the new technology.

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.

>> 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.

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.
This means surprises are bound to happen. 

>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.

If you try xterm -fg '#ffff00' -bg '#ffffff', and test all 6 colors,
you will see that only three combinations have enough contrast.
If you try it with black background, again there are 3 good 
combinations. 

The EGA colors contrast well. I don't think this is an accident.

>> 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.  These things are are often described as user
preferences. 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. 

-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: face at point

[Eli Zaretskii]

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).

Re: face at point

[Miles Bader]

Fredrik Staxeng <fstx+u@update.uu.se> writes:
> preferences. 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. 

... which is a bogus conclusion.

People _do_ say `hey these colors look like crap, lets change them,'
but often result is some combination of (1) `um, I kinda like them', or 
(2) `they've been that way for 15 years, we'd better not touch them,' or
(3) `maybe we have to do a poll to see if users will object,' ... etc.

All of those responses are in fact valid objections, and anyone who
really wants to clean up emacs' colors has to be able to deal with them.
If someone suceeds in doing so, then the discussion often mires down
into an argument about what the best replacements are.  Since all the
maintainers have usually already customized the colors they hate, it
often doesn't seem worth the effort (remember: many people work on emacs
because _they_ want to use it, not out of some spirit of giving).

I think the light-background defaults stink, but to tell the truth, I
really don't care that much, because I use a black background.  I
_am_ willing to push harder for a dark-background change, and have done
so (and I think the dark-background defaults are in fact better, though
still hardly perfect).

So say what you will about the results (hey everybody has an opinion),
the reasons are not quite so obvious.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: face at point

[Kai Großjohann]

Fredrik Staxeng <fstx+u@update.uu.se> writes:

> That was one possible explanation why one face might work on 
> black-on-white, but not black-on-white.

Are you aware that Emacs chooses different colors for a dark
background than for a light background?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: face at point

[Tim Cross]

Miles Bader <miles@lsi.nec.co.jp> writes:

> 
> > remember seeing some thread in one of the groups which recommended not
> > use the window-system variable (can't remember why).  For my setup I'm
> > using the function device-type e.g.
> 
> My emacs has no such function.
> 
> Are you perchance using xemacs?  If so, I think much of what I said
> above may not apply.  In particular, I was under the impression that
> xemacs had far less sophisticated handling of tty faces.
> 
> [Your email headers say `Emacs 21.2' though, so I'm not sure what to think...]
> 
,----[ C-h f device-type RET ]
| device-type is a compiled Lisp function.
| (device-type &optional DEVICE)
| 
| Return the type of the specified device (e.g. `x' or `tty').
| Value is `tty' for a tty device (a character-only terminal),
| `x' for a device which is a connection to an X server,
| 'ns' for a device which is a connection to a NeXTStep dps server,
| 'win32' or 'w32' for a Windows-NT window,
| 'pm' for an OS/2 Presentation Manager window,
| 'intuition' for an Amiga screen
`----

Would you consider the default colour for cited text in gnus when
following up to a post as being "broken" because its "red" on a black
background? Personally, I find this difficult to read, but maybe
others would not.

Tim

Re: face at point

[Jesper Harder]

Tim Cross <tcross@nospam.une.edu.au> writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
>
>> > For my setup I'm using the function device-type e.g.
>> 
>> My emacs has no such function.
>> 
>> Are you perchance using xemacs?
>
> ,----[ C-h f device-type RET ]
> | device-type is a compiled Lisp function.
> | (device-type &optional DEVICE)

FWIW, this function comes from w3.

w3 uses the XEmacs model and therefore supplies `device-type' in a
compatibility library, 'devices.el'.

Re: face at point

[Miles Bader]

Jesper Harder <harder@myrealbox.com> writes:
> > ,----[ C-h f device-type RET ]
> > | device-type is a compiled Lisp function.
> > | (device-type &optional DEVICE)
> 
> FWIW, this function comes from w3.
> 
> w3 uses the XEmacs model and therefore supplies `device-type' in a
> compatibility library, 'devices.el'.

I wish someone would fix w3; those compatibility functions often cause
real lossage, not just confusion (though they cause the latter in
copious amounts too).

[The problem is that w3 doesn't use its own namespace for them, which
sometimes causes _other_ packages that test for certain functions to
mistakenly think they're running under xemacs!  W3 should use
`w3-device-type' or something.]

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: face at point

[Miles Bader]

Tim Cross <tcross@nospam.une.edu.au> writes:
> Would you consider the default colour for cited text in gnus when
> following up to a post as being "broken" because its "red" on a black
> background? Personally, I find this difficult to read, but maybe
> others would not.

I don't particularly like this default, and in fact have it changed in
my personal configuration, but looking at the default now, I find it
more `annoying' than `difficult to read.'  I presume that the intent of
using that particular sort of (somewhat dim) color is to make the cited
text recede into the background, so that the text you're typing stands
out.  [I personally use `Orange2'; what do you think of that?]

As always, tastes vary, so it's possible that this _has_ been discussed
and no consensus to change it reached, but Emacs (and Gnus in
particular) has so many different faces that maybe everybody found it
easier to change it personally rather than to argue about it.

As Eli said in an earlier message, there is an informal policy to try
to keep the light-background and dark-background variants of a face at
least `similar,' which sometimes complicates things.

What color do you use for this face?

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: face at point

[Eli Zaretskii]

On 19 Nov 2002, Miles Bader wrote:

> it's possible that this _has_ been discussed
> and no consensus to change it reached, but Emacs (and Gnus in
> particular) has so many different faces that maybe everybody found it
> easier to change it personally rather than to argue about it.

IIRC, the discussions were only about the standard faces.  Faces defined 
by Gnus and other optional packages were not among them, to the best of 
my (failing) memory.

Re: face at point

[Tim Cross]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Tim Cross <tcross@nospam.une.edu.au> writes:
> As Eli said in an earlier message, there is an informal policy to try
> to keep the light-background and dark-background variants of a face at
> least `similar,' which sometimes complicates things.
> 
> What color do you use for this face?
> 

At present, within Gnus, I'm still using the default, so its still in
'difficult red'. I like the idea of orange, or maybe a lighter
red/pink - I do try to stay close to what the defaults are -
experience has taught nme that if you change colours too dramatically,
you end up conflicting in other areas and having to change yet more
fonts, leading to changing more fonts .....

On an even more interesting note was the comments in another part of
this thread which points out the function I have been using to
determine the type o device I'm on and therefore the type of colours
to use is actually from w3 (device0-type). I didn't realise this and
now think that although it does the job, its not the best choice to
use. 

Is it OK to just use the window-system variable? I can't remember what
the discussion was some time ago that seemed to conclude it was a bad
idea. If you are better off not using it, what would be best? ideally,
I'd like something that can tell the difference between X, the console
and a colour xterm. From my apropos searches, it seems there is quite
a few to choose from and can already see how to make a number of
alternatives work, but would just like to know how others have
approached this and why they chose the method they did.

Tim

Re: face at point

[Eli Zaretskii]

On 19 Nov 2002, Tim Cross wrote:

> Is it OK to just use the window-system variable? I can't remember what
> the discussion was some time ago that seemed to conclude it was a bad
> idea. If you are better off not using it, what would be best?

If you want to know whether the display is a bitmapped graphical one or a 
text-mode one, use display-graphic-p.  If you want to distinguish 
displays according to the number of distinct colors they support, look at 
the number that display-color-cells returns.

> ideally,
> I'd like something that can tell the difference between X, the console
> and a colour xterm.

To distinguish between a console and xterm, try something like what 
startup.el does:

                  (setq term (getenv "TERM"))
                  ;; Some files in lisp/term do a better job with the
                  ;; background mode, but we leave this here anyway, in
                  ;; case they remove those files.
                  (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
                                    term)
		      ;; code that should run for xterm

> From my apropos searches, it seems there is quite
> a few to choose from and can already see how to make a number of
> alternatives work

If the ELisp manual in its node that describes display capabilities 
doesn't explain how to do what you want, please submit a docs bug 
report.  Thanks.

Re: face at point

[Fredrik Staxeng]

Miles Bader <miles@lsi.nec.co.jp> writes:

>As Eli said in an earlier message, there is an informal policy to try
>to keep the light-background and dark-background variants of a face at
>least `similar,' which sometimes complicates things.
        ^^^^^^^

This is neither possible or desirable. A black background needs
a light foreground color, and vice versa. Yellow work against
black background, but there is no yellowish color that works 
against white. Cyan and magenta work a _tiny_ bit better, you 
can read the text, but they still don't make good foregrounds
on white.


-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr

Re: face at point

[Eli Zaretskii]

On 19 Nov 2002, Fredrik Staxeng wrote:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> >As Eli said in an earlier message, there is an informal policy to try
> >to keep the light-background and dark-background variants of a face at
> >least `similar,' which sometimes complicates things.
>         ^^^^^^^
> 
> This is neither possible or desirable.

I think it's desirable whenever it's possible ;-)

That is, if we can come up with similar foreground colors that look well 
on both light and dark backgrounds, there's nothing wrong with using them.

When it's impossible to have similar colors on both types of background, 
Emacs defines different colors.

The rationale for using similar colors is so that users won't need to 
relearn the meaning of each color when they switch background modes.  For 
example, if a face for comments is always reddish, it helps the users to 
find comments quickly in any mode on any display.  By contrast, if a 
comment is sometimes reddish and sometimes greenish, users might get 
confused, and documentation is hard to write.

> A black background needs
> a light foreground color, and vice versa.

Sure, but they could be dark and light shades of the same or similar 
colors.

> Yellow work against
> black background, but there is no yellowish color that works 
> against white.

Really?  Aren't dark goldenrod or similar look good enough on light 
background?  Are you saying that there's _no_ color in what 
`list-colors-display' produces that's yellowish and is reasonably readable 
on light background?

> Cyan and magenta work a _tiny_ bit better, you 
> can read the text, but they still don't make good foregrounds
> on white.

I find that several shades of magenta are readable on the default light 
background Emacs presents on X.

Re: face at point

[Miles Bader]

Fredrik Staxeng <fstx+u@update.uu.se> writes:
> > As Eli said in an earlier message, there is an informal policy to try
> > to keep the light-background and dark-background variants of a face at
> > least `similar,' which sometimes complicates things.
>         ^^^^^^^
> 
> This is neither possible or desirable.

Whether it's `desirable' or not, I really don't know -- but it seems
like a non-unreasonable default position.

As for possible, of course it's sometimes not possible, but quite often
it is.  When it isn't possible to use _literally_ the same color, I'll
usually try to use something similar in spirit, e.g., if the existing
default is something like dark-blue, which looks good against a
light-background, but not against a dark-background, I'll often try to
use a light-blue for the dark-background case instead.

And lastly, please don't be so condescending.  We may have different
tastes than you in some cases, but we aren't idiots.

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: face at point

[Fredrik Staxeng]

Miles Bader <miles@lsi.nec.co.jp> writes:

>Fredrik Staxeng <fstx+u@update.uu.se> writes:
>> > As Eli said in an earlier message, there is an informal policy to try
>> > to keep the light-background and dark-background variants of a face at
>> > least `similar,' which sometimes complicates things.
>>         ^^^^^^^
>> 
>> This is neither possible or desirable.
>
>Whether it's `desirable' or not, I really don't know -- but it seems
>like a non-unreasonable default position.

I apologize for that expression. 

But I gave some examples to illustrate what I meant. I think that the
set of colors that work well on white backgrounds and the set of
colors that work well on black backgrounds have an almost empty
intersection. 

Of course, if you by similar mean the nearest ones from the two sets,
there is much less of an argument. The result is readable. 

But I hastily interpreted that as "only change the colors that we absolutely
have to change". 

>As for possible, of course it's sometimes not possible, but quite often
>it is.  When it isn't possible to use _literally_ the same color, I'll
>usually try to use something similar in spirit, e.g., if the existing
>default is something like dark-blue, which looks good against a
>light-background, but not against a dark-background, I'll often try to
>use a light-blue for the dark-background case instead.

That is the way to do it. The important thing is that you consider
the background. Emacs is the only program I know that even try to
do this.

>And lastly, please don't be so condescending.  We may have different
>tastes than you in some cases, but we aren't idiots.

Sorry. 


-- 
Fredrik Stax\"ang | rot13: sfgk@hcqngr.hh.fr