Re: (type graphic)

[Miles Bader]

Eli Zaretskii <address@hidden> writes:
> However, if we want to change this, we might as well do it right ;-)

Good point.

> If the number of supported colors is the _only_ reason, we can simply 
> test how many colors are supported, and act accordingly, or define a 
> new type, say '256color, to check inside defface instead 'tty.
> 
> If there are other reasons for the distinction between display types 
> inside defface, let's hear them.

Ok, off the top of my head:

  * Underline    [graphic: always yes, tty: if has TC entry]
  * Italic       [graphic: always yes, tty: not on any model I know]
  * Boxes        [graphic: always yes, tty: prob always no]
  * Font sizes   [graphic: always yes, tty: prob always no]
  * Font weights [graphic: mostly yes, tty: if has TC entry, usally only bold]
  * Variant widths [graphic: mostly yes, tty: almost always no, or TC entry]
  * Overline     [graphic: always yes, tty: prob always no]
  * Strike thru  [graphic: always yes, tty: prob always no]
  * # of Colors  [graphic & tty have similar issues, but this could
                  be thought of as being under the `class' tag, not the
                  `type' tag]

You can see there's an obvious pattern above...  So (type graphic/tty)
*does* have some meaning, until there's a better mechanism.

Perhaps a better way would be to add a `supported' tag, and also extend
the existing `color' tag, where the arguments are face attribute names
(or pseudo attribute names like :italic).  For instance:

  (defface my-emphasis
    '((((supported :italic))    :slant italic)
      (((supported :height))    :height 2.0)
      (((supported :underline)) :underline t)
      (t                        :inverse-video t)))

As for the color-tag, I'm not sure.  How about if an argument to `color'
is an integer, then the test succeeds when the number of supported of
colors is >= the argument.  [This obviously relies on low-color
terminals all supporting a "similar" set of colors]

Comments?

-Miles