headers
Eli Zaretskii | 1 Mar 2004 06:50
Picon

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

> From: "Jan D." <jan.h.d <at> 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.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Mar 2004 07:00
Picon

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

> Date: Sun, 29 Feb 2004 17:03:41 -0500
> From: Miles Bader <miles <at> 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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Eli Zaretskii | 1 Mar 2004 07:07
Picon

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

> From: Jason Rumney <jasonr <at> gnu.org>
> Date: 29 Feb 2004 22:39:21 +0000
> 
> "Eli Zaretskii" <eliz <at> 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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Miles Bader | 1 Mar 2004 07:24
Picon
Picon

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

"Eli Zaretskii" <eliz <at> 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.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jason Rumney | 1 Mar 2004 09:30
Picon

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

"Eli Zaretskii" <eliz <at> 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 */
Permalink | Reply | 2 comments |
headers
Jan D. | 1 Mar 2004 10:39
Picon

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

> 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.
Permalink | Reply | 0 comments |
headers
Kim F. Storm | 1 Mar 2004 11:47
Picon

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

Luc Teirlinck <teirllm <at> 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
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Mar 2004 13:11
Picon
Picon

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

    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.
Permalink | Reply | 0 comments |
headers
Jan D. | 1 Mar 2004 13:55
Picon

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

> 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.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Mar 2004 20:55
Picon

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

> From: Miles Bader <miles <at> 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.
Permalink | Reply | 6 comments |

Gmane