Re: (type graphic)

[Eli Zaretskii]

> From: Jason Rumney <address@hidden>
> Date: Wed, 25 Oct 2000 19:55:10 +0100
> 
> To clarify for Eli, the face definitions that Miles is talking about
> are those which take on a raised button appearance.

After resynching with the CVS and playing a bit with the new version,
the above assertion doesn't seem to be true.  That's because the new
code, to wit:

            match (cond ((eq req 'type)
                         (or (memq window-system options)
                             (if (display-graphic-p frame)
                                 (memq 'graphic options)
                               (memq 'tty options))

is used for *all* faces, not just for those where the face
definition says (type graphic).

The net effect is that the new code causes the tty colors to be used
for the MS-DOS port, whereas previously it used the X colors
(approximated by tty-colors.el).  The result of this is that almost
all of the default colors in the MS-DOS port got redefined en masse,
and the new definitions are generally much worse, since (1) they are
based on dark background, whereas the MS-DOS port works by default in
light (lightgray) background mode; and (2) they are suited for 8-color
terminals, and thus several faces have identical colors.

There are 3 possible solutions to this:

  1) Introduce specific definitions for (type pc).

  2) Revert the change done by Miles.

  3) Replace (type tty) with (type 8-color), or with some other magic
     that looks at the number of the supported colors.

The first alternative is IMHO a step in the wrong direction: we
introduced the transparanet X color mapping to _avoid_ segregation of
different display types, not to proliferate them.  Having several
different definitions makes maintenance much harder.  I tried very
hard to resist pc-specific color definitions, precisely for these
reasons, and my experience is that the X color definitions work quite
well for the MS-DOS console.

(Btw, ideally, we should have removed all (type tty) definitions in
deffaces, and try to see whether the result is reasonable; then we
could add tty-specific colors only where the color mapping isn't good
enough.)

The 3rd alternative is probably the Right Way in the long run.
However, it requires lots of editing of all defface's, and might also
need non-trivial changes to the code on faces.el which parses defface.

I would not want to destabilize the code by introducing option 3 now,
or by editing many face definitions, but I don't like the drastic
change in colors caused by the above code snippet, either.  So I
suggest to take out that change, and add a TODO item for after v21.1,
to reduce the number of tty-specific color definitions as much as
possible, and base those which will be left on the number of supported
colors rather than on the frame type.

Comments?  Thoughts?  Flames?