Re: terminal capability querying

[Miles Bader <miles@gnu.org>]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> >   (display-capable-p ATTRIBUTE &optional DISPLAY)
> > 
> >     Return non-nil if DISPLAY supports the face attribute ATTRIBUTE.
> 
> Could we change the name to something like display-attributes-p, or
> even display-text-attributes-p?  display-capable-p sounds too general
> for the specific purpose you have in mind (if I understand you well).

[The inspiration for the name was the common phrase `terminal
 capability', but that's just an aside.]

Point taken, although most of the names I can think of that are truly
descriptive are rather um, lengthy, e.g., `display-supports-face-attribute-p'.

But I guess that's not entirely a bad thing, as calls to this function
probably won't be littering the code (people should usually create a
face instead).

> >     ATTRIBUTE should be either the name of a face attribute, e.g.,
> >     `:weight', `:underline', etc., or a cons-cell or list containing a
> >     face attribute and a specific value for it, e.g., (:weight bold).
> 
> If we intend to use this mainly for a tty (I guess windowed displays
> will always pass all these tests), it's perhaps better to use `:bold'
> directly, since terminals generally don't support more than a single
> value of `weight'.  The same goes for `:slant': I think it's better
> to use `:italic'.

The use of existing face attribute names is intentional (since I want to
use this call to support the defface `or'-vector concept that I
described in my followup message), so it should at least _support_ those
:weight, :slant, etc (which note aren't really supported in their full
generality by most X fonts either).

It might be convenient to have short-cuts like :bold or :italic; however,
my intention was that programs normally not call this function directly,
but rather use it indirectly though defface `or'-vectors, so perhaps
it's not really needed.  I don't know.

Also, note that this call actually _is_ useful on a non-tty display --
querying (:foreground "red") will return false on a non-color display,
and querying (:foreground "grey85") should return false on a
black-and-white display.  Of course one can find out this information
in other ways, but this one may be more convenient, especially if used
indirectly through defface.

> What about `dim' and `blink', btw?

dim:    (:weight SOMETHING-LESS-THAN-NORMAL) ?

blink:  Not very useful unless you can create a face display it, so we
        should think about adding that capability to faces first -- and
        then this function can use the same attribute that faces use.

> There's one other piece of work that IMHO needs to be done to make
> defface better: the ability to test for the number of supported
> colors.

I agree, but note that this may not be as necessary if we implement this
`display-...-p' function correctly; my thought about how to handle
explicit color tests was:

   If the user queries about, say, (:background "springgreen"), for
   low-color displays such as ttys, it could search through the list of
   colors, see if there's a displayable background color that's within
   some epsilon, and return false if there's not.  [You're the tty-color
   expert here, so perhaps you have some ideas here.]

If we do that, then you could just use defface specifications like

   (:weight bold
    :foreground "black"
    [(:background "springgreen")
     (:background "cyan")
     (:background "grey70")])

which would then use a `springgreen' background for displays that
support it reasonably well, like X displays or 256-color ttys, and fall
back to (presumably) safer alternative `cyan' for low-color displays,
or `grey70' for greyscale displays [and the lattern should degrade to
simply `white' for black-and-white displays].  No #-of-colors tests,
but nice, flexible behavior on lots of display types!

-Miles
-- 
Fast, small, soon; pick any 2.