[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: terminal capability querying
Re: terminal capability querying
20 Apr 2002 17:12:58 +0900
"Eli Zaretskii" <address@hidden> 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
> > 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
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
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!
Fast, small, soon; pick any 2.
Re: terminal capability querying, Richard Stallman, 2002/04/21