Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

> "Jan D." <jan.h.d@swipnet.se> writes:
>
>>>   (x-display-color-cells) => 64
>>>
>>> I noticed because of the recent change in font-lock.el -- since
>>> 64 < 88 I now get really ugly font-lock colours.
>>
>> This function does not look to have been changed for a very long time.
>> It basically just returns
>> DisplayCells (dpyinfo->display,
>>                XScreenNumberOfScreen (dpyinfo->screen))
>>
>> Have you changed X server lately?
>
> No.  `x-display-color-cells' has probably always returned 64 (it also
> does that in Emacs 21.3), but I guess it just wasn't used anywhere
> important before now.

Well, looking at your xdpyinfo, the only thing it can return is 64.
But this is not the problem you have.  What you are saying is that
64 works fine as a value for min-colors in font-lock.el instead of
88.  Your problem has nothing to do with x-display-color-cells.

88 is a funny value, I don't know how that value was reached, Cc:ing
emacs-devel to see if anybody can help.

	Jan D.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 29 Feb 2004 18:01:09 +0100
> 
> 88 is a funny value, I don't know how that value was reached, Cc:ing
> emacs-devel to see if anybody can help.

88 was chosen because neither myself nor Dan Nicalaescu thought about
any values between 88 and 16 that Emacs bumps into on color displays.
I suggested to Dan that, since 88 colors seems to be enough to have
good approximations to all colors used by standard faces, to set the
breaking point at 88.  If 64 is good enough for that, we should
probably change that to 64.

However, this sounds like a tip of an iceberg: are you saying that
list-display-colors will display a list whose length has no simple
relation to what display-color-cells returns?  That sounds bad,
doesn't it?

Re: Font-lock.el uses strange value for min-colors

[Jesper Harder]

"Jan D." <jan.h.d@swipnet.se> writes:

>> No.  `x-display-color-cells' has probably always returned 64 (it
>> also does that in Emacs 21.3), but I guess it just wasn't used
>> anywhere important before now.
>
> Well, looking at your xdpyinfo, the only thing it can return is 64.
> But this is not the problem you have.  What you are saying is that
> 64 works fine as a value for min-colors in font-lock.el instead of
> 88.  Your problem has nothing to do with x-display-color-cells.

Yes, you're right.  Come to think of it, I don't even know what
"number of color cells" means :-)

It clearly doesn't mean the number of available colours, since
`list-colors-display' shows much more than 64 colours.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Luc Teirlinck]

Jan D. wrote:

   Cc:ing emacs-devel to see if anybody can help.

I somehow have the impression that anything sent to emacs-devel has
been redirected to /dev/null since Wednesday evening.

Sincerely,

Luc.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

> However, this sounds like a tip of an iceberg: are you saying that
> list-display-colors will display a list whose length has no simple
> relation to what display-color-cells returns?  That sounds bad,
> doesn't it?

Bad or not, it is the case.  An X server is free to use just about any 
value
for DisplayCells, it is just the number of cells you get by default
when creating a colormap.  In this case, Jesper Harder has 16 planes, 
but
just 64 color cells.  So he can actually display 65536 colors, not 64.
However, he also has a TrueColor visual, so Emacs should see this and
ignore DisplayCells, I don't know why it doesn't.  I see that
list-colors-display has code to ignore DisplayCells for TrueColor 
visuals.

It is actually uncommon for any X server to return more than 256 for
DisplayCells, presumably to save memory if a lot of colormaps are
allocated.

A better way to find out the number of colors that can be displayed
at the same time is (1 << DisplayPlanes(...)).  There is no need to
distinguish between visual types if number of colors is calculated this
way.

	Jan D.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

> Jan D. wrote:
>
>    Cc:ing emacs-devel to see if anybody can help.
>
> I somehow have the impression that anything sent to emacs-devel has
> been redirected to /dev/null since Wednesday evening.
>
> Sincerely,
>
> Luc.

Hmm, you may be correct, there is nothing archived after Wednesday, and
I haven't seen my messages returned yet.  However, I have a faint memory
of seeing messages after Wednesday, but they may have been from pretest.
If I don't see anything by tomorrow I will send a message to savannah
hackers.

	Jan D.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Luc Teirlinck]

Jan D. wrote:

   If I don't see anything by tomorrow I will send a message to savannah
   hackers.

I do not believe that Savannah hackers manages the emacs-devel mailing
list.  Should that not be sent to mailman@mail.gnu.org?  But I am not
completely sure that even that would be the right place, since the
problem seems to be specific to emacs-devel.  Other mailing lists seem
to be unaffected.  Although a message I received as private mail from
Stefan on February 24 (a patch for a problem about filling Elisp
docstrings containing semicolons) had a CC to emacs-pretest-bug, which
apparently has been redirected to /dev/null too.  At least, I do not
remember ever seeing it appear on emacs-pretest-bug and the archives
say "Message not available".

Sincerely,

Luc.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

> I do not believe that Savannah hackers manages the emacs-devel mailing
> list.  Should that not be sent to mailman@mail.gnu.org?  But I am not

Yes of course, my bad.


> completely sure that even that would be the right place, since the
> problem seems to be specific to emacs-devel.  Other mailing lists seem
> to be unaffected.  Although a message I received as private mail from
> Stefan on February 24 (a patch for a problem about filling Elisp
> docstrings containing semicolons) had a CC to emacs-pretest-bug, which
> apparently has been redirected to /dev/null too.  At least, I do not
> remember ever seeing it appear on emacs-pretest-bug and the archives
> say "Message not available".

I do see my messages on pretest-bug now at least.  Maybe it was a 
temporary
failure?

	Jan D.

Re: Font-lock.el uses strange value for min-colors

[Eli Zaretskii]

> From: Jesper Harder <harder@ifa.au.dk>
> Date: Sun, 29 Feb 2004 19:18:10 +0100
> 
> It clearly doesn't mean the number of available colours, since
> `list-colors-display' shows much more than 64 colours.

On X, `list-colors-display' currently displays the colors whose list
is in x-win.el, IIRC.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 29 Feb 2004 20:27:56 +0100
> 
> It is actually uncommon for any X server to return more than 256 for
> DisplayCells, presumably to save memory if a lot of colormaps are
> allocated.
> 
> A better way to find out the number of colors that can be displayed
> at the same time is (1 << DisplayPlanes(...)).  There is no need to
> distinguish between visual types if number of colors is calculated this
> way.

I don't know enough about X to even parse the last sentence, but I do
think display-color-cells should return the number of distinct colors
Emacs can use.  It sounds like display-color-cells does that on every
platform except X (MS-Windows, MS-DOS, Unix tty, don't know about the
Mac).  That function is advertised as one that returns the number of
distinct colors, so IMHO it had better do what we say it does.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Luc Teirlinck]

The one failure on emacs-pretest-bug I know of seems to have been an
isolated incident.  However, I do not remember seeing any messages
from emacs-devel since Wednesday evening and three messages I sent
several days ago have not arrived.  I doubt they ever will.

Sincerely,

Luc.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

>> A better way to find out the number of colors that can be displayed
>> at the same time is (1 << DisplayPlanes(...)).  There is no need to
>> distinguish between visual types if number of colors is calculated 
>> this
>> way.
>
> I don't know enough about X to even parse the last sentence, but I do
> think display-color-cells should return the number of distinct colors
> Emacs can use.  It sounds like display-color-cells does that on every
> platform except X (MS-Windows, MS-DOS, Unix tty, don't know about the
> Mac).  That function is advertised as one that returns the number of
> distinct colors, so IMHO it had better do what we say it does.

The number of planes it the same as the number of bits in a pixel,
i.e. 8 for 256 color displays, 16 for 65536 colors, and so on.

So on X the number of colors Emacs can use are
   (ash 1 (x-display-planes))

I can do the change, but I don't know if x-display-color-cells or
display-color-cells should change yet.  I'll have to check where
else x-display-color-cells is used.  I will do it within a day or so.

	Jan D.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Miles Bader]

On Sun, Feb 29, 2004 at 08:14:24PM +0200, Eli Zaretskii wrote:
> However, this sounds like a tip of an iceberg: are you saying that
> list-display-colors will display a list whose length has no simple
> relation to what display-color-cells returns?  That sounds bad,
> doesn't it?

Um, no.  [I presume you meant `list-colors-display',]

Perhaps the doc string should be more clear about it [though I suppose
technically it's accurate, as it makes no mention of being exhaustive], but
the default behavior on X is to display a list of `interesting' colors (those
with names).  Such a list is more likely to emphasize colors that are
interesting to human eyes, and I doubt that anyone cares whether such it has
any simple relationship to the number of possible colors when its length is
above about a 100 or so -- you can still, obviously, use the #xxx notation to
get any color you want.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jason Rumney]

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

> It sounds like display-color-cells does that on every platform
> except X 

Since color-cells is originally an X concept, I think those other
platforms only do that because of a lack of understanding about what X
really means by color-cells. It does seem like display-planes is more
reliable at least on X and W32 (where it was fixed to mean the same as
X some time ago, since W32 has a different idea of planes), so how
about changing the calculation of min-colors in faces.el to

      (>= (expt 2.0 (display-planes frame)) (car options))

2.0 seems to be required (as opposed to 2) to force floating point in
case of 32 bit displays, this might be a bug in Emacs, perhaps expt
and other math functions should detect integer overflow and use
floating point automatically?

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Sun, 29 Feb 2004 22:58:52 +0100
> 
> So on X the number of colors Emacs can use are
>    (ash 1 (x-display-planes))
> 
> I can do the change, but I don't know if x-display-color-cells or
> display-color-cells should change yet.  I'll have to check where
> else x-display-color-cells is used.  I will do it within a day or so.

Thank you.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> Date: Sun, 29 Feb 2004 17:03:41 -0500
> From: Miles Bader <miles@gnu.org>
> 
> On Sun, Feb 29, 2004 at 08:14:24PM +0200, Eli Zaretskii wrote:
> > However, this sounds like a tip of an iceberg: are you saying that
> > list-display-colors will display a list whose length has no simple
> > relation to what display-color-cells returns?  That sounds bad,
> > doesn't it?
> 
> Um, no.  [I presume you meant `list-colors-display',]

Yes, sorry for the typo.

> Perhaps the doc string should be more clear about it [though I suppose
> technically it's accurate, as it makes no mention of being exhaustive], but
> the default behavior on X is to display a list of `interesting' colors (those
> with names).  Such a list is more likely to emphasize colors that are
> interesting to human eyes, and I doubt that anyone cares whether such it has
> any simple relationship to the number of possible colors when its length is
> above about a 100 or so -- you can still, obviously, use the #xxx notation to
> get any color you want.

I know that the list of colors displayed by list-colors-display on X
is fixed (see my message earlier in this thread), but I always
thought, I don't know why, that the length of that list is near the
number returned by display-color-cells.

If this is not true, one may ask what is so ``interesting'' about the
specific colors we show as opposed to those we don't.  For example,
when I work on Irix, I generally like to use the Irix-specific colors
(that are not shown by list-colors-display, of course) because they
are much more pleasant to my eyes.  So to me, those unshown colors are
much more ``interesting'' than those we show, in that specific case.

The importance of list-colors-display is that some people use it to
choose colors for their customizations, so the shown colors need to
have some resemblance to what Emacs can support.

Bottom line is, I think list-colors-display should display colors
whose number is close to what Emacs can use on that display, except
that it probably shouldn't be too long (so I don't suggest to display
64K colors, for example).  Perhaps a short comment to the effect that
we are showing only N out of possible M colors would be good there.

But this is not the gravest problem with this issue; see my other
messages about the value returned by display-color-cells, which I
think is the main issue here.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 29 Feb 2004 22:39:21 +0000
> 
> "Eli Zaretskii" <eliz@elta.co.il> writes:
> 
> > It sounds like display-color-cells does that on every platform
> > except X 
> 
> Since color-cells is originally an X concept, I think those other
> platforms only do that because of a lack of understanding about what X
> really means by color-cells. It does seem like display-planes is more
> reliable at least on X and W32 (where it was fixed to mean the same as
> X some time ago, since W32 has a different idea of planes), so how
> about changing the calculation of min-colors in faces.el to
> 
>       (>= (expt 2.0 (display-planes frame)) (car options))

I'd rather not do this.  display-color-cells was written to return the
number of supported colors, period.  (The fact that the name says
color-cells is a bow to the X-specific function that was supposed to
return the same value on X, and otherwise has no other meaning.  The
names of all display-* functions were reviewed and approved by Richard
at least, so it's not only my own misunderstanding of X that went into
the design and the name.)

So I'd rather modify the definition of display-color-cells on X along
the lines suggested by Jan to bring that function up to what its docs
advertise.

> 2.0 seems to be required (as opposed to 2) to force floating point in
> case of 32 bit displays, this might be a bug in Emacs

It's a feature, see the function's code on floatfns.c.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Miles Bader]

"Eli Zaretskii" <eliz@elta.co.il> writes:
> when I work on Irix, I generally like to use the Irix-specific colors
> (that are not shown by list-colors-display, of course) because they
> are much more pleasant to my eyes.  So to me, those unshown colors are
> much more ``interesting'' than those we show, in that specific case.

If you can come up with a reasonable list of `irix colors' that seems
appropriate, feel free (modulo code-bloat/why-are-we-spending-
time-worrying-about-silly-things-like-this issues)...

> Bottom line is, I think list-colors-display should display colors
> whose number is close to what Emacs can use on that display, except
> that it probably shouldn't be too long (so I don't suggest to display
> 64K colors, for example).

There are only a few important cases in practice -- monochrome,
low-color (e.g. 8 color) displays, 256-color (8 bit) displays, and
everything else.  The current behavior seems to be basically same as
what you want for most common displays; if you really care, I suppose
you could look into making it work well in other rarer cases (but I
suppose that you probably don't care enough).

> Perhaps a short comment to the effect that
> we are showing only N out of possible M colors would be good there.

Yes, that would be handy; perhaps it could also mention using the
`#rrggbb' notation to get colors not displayed in the list.

This change would be simple and I think probably good enough.

-Miles
-- 
97% of everything is grunge

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jason Rumney]

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

> > 2.0 seems to be required (as opposed to 2) to force floating point in
> > case of 32 bit displays, this might be a bug in Emacs
> 
> It's a feature, see the function's code on floatfns.c.

This comment seems to indicate that its more a known bug than a feature:

  /* Really should check for overflow, too */

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

> I know that the list of colors displayed by list-colors-display on X
> is fixed (see my message earlier in this thread), but I always
> thought, I don't know why, that the length of that list is near the
> number returned by display-color-cells.
>
> If this is not true, one may ask what is so ``interesting'' about the
> specific colors we show as opposed to those we don't.  For example,
> when I work on Irix, I generally like to use the Irix-specific colors
> (that are not shown by list-colors-display, of course) because they
> are much more pleasant to my eyes.  So to me, those unshown colors are
> much more ``interesting'' than those we show, in that specific case.

Emacs could read the rgb.txt file and add colors from that file into
the list.  Or better, execute showrgb and catch the output.  That way
Emacs does not have to worry where the rgb.txt file is.  But this
may too slow, I haven't tested it.

I assume those Irix colors are shown by showrgb.

	Jan D.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The one failure on emacs-pretest-bug I know of seems to have been an
> isolated incident.  However, I do not remember seeing any messages
> from emacs-devel since Wednesday evening and three messages I sent
> several days ago have not arrived.  I doubt they ever will.

My recent messages to emacs-devel have gone into the bit-bucket as
well.  The messages that I've received lately were all cross-posted to
pretest-bug.

-- 
Kim F. Storm  http://www.cua.dk

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Richard Stallman]

    If I don't see anything by tomorrow I will send a message to savannah
    hackers.

Savannah does not run our mailing lists, it just has an interface for
editing them.  So don't waste your time writing to savannah-hackers.

I wrote to sysadmin.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Jan D.]

> I can do the change, but I don't know if x-display-color-cells or
> display-color-cells should change yet.  I'll have to check where
> else x-display-color-cells is used.  I will do it within a day or so.

I've changed x-display-color-cells.  Can you rerun your test and see if it is 
better now?

Thanks,

	Jan D.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 01 Mar 2004 08:30:59 +0000
> 
> > It's a feature, see the function's code on floatfns.c.
> 
> This comment seems to indicate that its more a known bug than a feature:
> 
>   /* Really should check for overflow, too */

Perhaps I misunderstood you.  The code and the comments therein say
that the special behavior with integer argument is for compatibility
with Common Lisp.  That's what I meant when I said ``feature''.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 01 Mar 2004 15:24:52 +0900
> 
> > Bottom line is, I think list-colors-display should display colors
> > whose number is close to what Emacs can use on that display, except
> > that it probably shouldn't be too long (so I don't suggest to display
> > 64K colors, for example).
> 
> There are only a few important cases in practice -- monochrome,
> low-color (e.g. 8 color) displays, 256-color (8 bit) displays, and
> everything else.  The current behavior seems to be basically same as
> what you want for most common displays; if you really care, I suppose
> you could look into making it work well in other rarer cases (but I
> suppose that you probably don't care enough).

Getting reasonable results on X seems like something we should want, I
think.  Showing only 64 colors sounds like less than optimal behavior.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Miles Bader]

"Eli Zaretskii" <eliz@elta.co.il> writes:
> > The current behavior seems to be basically same as what you want for
> > most common displays; if you really care, I suppose you could look
> > into making it work well in other rarer cases (but I suppose that
> > you probably don't care enough).
> 
> Getting reasonable results on X seems like something we should want, I
> think.  Showing only 64 colors sounds like less than optimal behavior.

Huh?

`M-x list-colors-display' (under X)  shows for me ... 548 colors.
That seems reasonable.

-Miles
-- 
自らを空にして、心を開く時、道は開かれる

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 02 Mar 2004 11:24:07 +0900
> 
> > Getting reasonable results on X seems like something we should want, I
> > think.  Showing only 64 colors sounds like less than optimal behavior.
> 
> Huh?

I'd appreciate if that "Huh?" never saw the light of the day.

> `M-x list-colors-display' (under X)  shows for me ... 548 colors.
> That seems reasonable.

I meant display-color-cells.

Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number)

[Miles Bader]

Eli Zaretskii <eliz@elta.co.il> writes:
> > > Getting reasonable results on X seems like something we should want, I
> > > think.  Showing only 64 colors sounds like less than optimal behavior.
> > 
> > Huh?
> 
> I'd appreciate if that "Huh?" never saw the light of the day.

huh?

> > `M-x list-colors-display' (under X)  shows for me ... 548 colors.
> > That seems reasonable.
> 
> I meant display-color-cells.

Looking at the code, it _appears_ that list-colors-display attempts to
limit the display to the number of colors supported by the display
(though the method it uses is bogus), but apparently that didn't work
for some reason because list-colors-display displayed lots of colors for
me even when display-color-cells returned a small value on X.

Of course now, display-color-cells returns a proper value on X, so no
problem.  Well, except that the method used by list-colors-display to
limit the displayed colors is still bogus, so I suppose the result for
people with e.g. an 8-plane pseudo-color display will see non-optimal
results; I suspect such displays aren't all that common nowdays however
(though in fact, that's what I have at home!).

-miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'