[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Font-lock.el uses strange value for min-colors (Was x-display-color-
From: |
Eli Zaretskii |
Subject: |
Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number) |
Date: |
Mon, 01 Mar 2004 08:07:10 +0200 |
> From: Jason Rumney <address@hidden>
> Date: 29 Feb 2004 22:39:21 +0000
>
> "Eli Zaretskii" <address@hidden> 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), Jan D., 2004/03/01
Re: Font-lock.el uses strange value for min-colors (Was x-display-color-cells returns wrong number),
Eli Zaretskii <=