terminal capability querying

terminal capability querying

[Miles Bader]

[I brought up this same subject a long time ago, duing the 21.1 pretest,
 but that wasn't the right time to think about such issues]

One feature that I think would be useful and easy to implement would be
the ability to query what capabilities (e.g., underlining, boldface) are
supported when emacs is running on a tty.

For instance, for widget input fields, the most natural appearance would
seem to be underlining (like a real paper form), but since we can never
be sure that a terminal supports it, the face used for widget fields
must be conservative and defaults to a rather garish colored background
on ttys (unlike X displays, many 8/16-color ttys have no subtle colors
that are really nice for such an application).

For the same reason, other faces default to using combinations of
attributes (e.g. underlined+bold+colored) on ttys, just to be safe.
This means that probably at least one of the used attributes is
supported by any given terminal, and so the face will stand out, but
it often ends up looking unnecessarily busy on terminals that happen to
support all of the used attributes.

So, I propose adding the ability to ask emacs _which_ of these
capabilities a display supports, both in lisp code and in `defface'
specifications.  [This might end up making increasing the number of
clauses in defface specifications; I have another idea to help control
it, but I'll talk about that in another message.]

Here's a proposed programmatic interface:

  (display-capable-p ATTRIBUTE &optional DISPLAY)

    Return non-nil if DISPLAY supports the face attribute ATTRIBUTE.

    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 ATTRIBUTE is an attribute name, then non-nil is returned if the
    display supports any non-default value for that attribute.
    If ATTRIBUTE specifies a value as well, then non-nil is returned
    if the display supports either that specific value, or some
    non-default `close' value.

For defface specs, I propose adding a new defface test, `capable', that
has the same argument as `display-capable-p' (except that the two cases
can also be represented as either 1 or 2 args following the `capable'
keyword, instead of being either an atom or a list).

For instance, one might change the `italic' face to be like this:

(defface italic
  '(((capable :slant italic) :slant italic)
    ((capable :underline) :underline t)
    (t :slant italic))
  "Basic italic font."
  :group 'basic-faces)

as underlining is the conventional representation for italics when real
italics are not supported.

It's not at all hard to implement this, I think, so I will do so if no
one objects.

Comments?

Thanks,

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: terminal capability querying

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 20 Apr 2002 11:20:11 +0900
> 
> So, I propose adding the ability to ask emacs _which_ of these
> capabilities a display supports, both in lisp code and in `defface'
> specifications.

I think it's a good idea.

>   (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).

Otherwise, I like the design.

>     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'.

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

> It's not at all hard to implement this, I think, so I will do so if no
> one objects.

I'm for it.

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.  This is needed for supporting terminals that can display
large number of colors in text mode, such as recent versions of xterm.
We could then all but get rid of testing the frame type (`x', `w32',
`tty', etc.) in defface, and instead look at the number of supported
colors.  This has been on my todo for a long time, and I will do it as
soon as I can, but if someone feels to make it happen earlier...

Re: terminal capability querying

[Miles Bader]

"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.

Re: terminal capability querying

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 20 Apr 2002 17:12:58 +0900
>
>    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.]

Testing colors for how close they are is relatively easy.  In fact
tty-colors.el already implements two such measures; they might need
some simple generalizations, though.

>    (: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!

This will work well if we assume that color choices for foreground and
background are independent.  I suspect that it's not always so.  In
those cases where there's a dependency between the two colors, I think
we had better keep that dependency explicit in defface in some way
(although doing that via the number of supported colors is not the
only possible way).

The reason that foreground and background color selection might not be
independent is that for terminals that support a low number of colors,
simply peeking up the best approximation to the original X color might
produce unpleasant results.  So sometimes your vector of alternative
colors will have to specify a totally different foreground color for
low-end displays, and thus require a suitably different background
color.  The recent changes I did to Ediff colors is one case in point.

Re: terminal capability querying

[Miles Bader]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:
> > No #-of-colors tests, but nice, flexible behavior on lots of display
> > types!
> 
> This will work well if we assume that color choices for foreground and
> background are independent.  I suspect that it's not always so.  In
> those cases where there's a dependency between the two colors, I think
> we had better keep that dependency explicit in defface in some way
> (although doing that via the number of supported colors is not the
> only possible way).

Actually, it occured to me that it would be a nice feature to also allow
passing attribute lists to `display-supports-face-attribute-p' (or
whatever it ends up being called), e.g.:

  (display-supports-face-attribute-p '(:foreground "red" :background "white"))

In most cases the effect would be same as simply the `and' of the
individual attributes, but for others, it could use the extra info to
return more `intelligent' results; in the case where both :foreground
and :background are specified, for instance, it could at least ensure
that the colors are `different".

For X displays, it could use more fully-specified font info to test, for
instance, if a font _really_ has a bold-faced font in a particular
family.  For instance, it might return true for '(:weight bold) but
nil for '(:family "wackyfont" :weight "bold") -- many non-standard
fonts lack bold-faced variants.

Since a list of attributes is the form that occurs naturally in the
defface `or'-vectors I described, this would directly benefit people
using defface (and make defface's job even easier).

> So sometimes your vector of alternative colors will have to specify a
> totally different foreground color for low-end displays, and thus
> require a suitably different background color.

I agree, sometimes it's going to be necessary to use special cases, so
it's clearly necessary to be able to do low-level tests like the number
colors, but I'd like to avoid it as much as possible. 

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: terminal capability querying

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: 20 Apr 2002 18:58:57 +0900
> 
> Actually, it occured to me that it would be a nice feature to also allow
> passing attribute lists to `display-supports-face-attribute-p' (or
> whatever it ends up being called), e.g.:
> 
>   (display-supports-face-attribute-p '(:foreground "red" :background "white"))
> 
> In most cases the effect would be same as simply the `and' of the
> individual attributes, but for others, it could use the extra info to
> return more `intelligent' results; in the case where both :foreground
> and :background are specified, for instance, it could at least ensure
> that the colors are `different".

Yes, it would be good to have that.  We could also teach this
function about unpleasant color combinations.

> I agree, sometimes it's going to be necessary to use special cases, so
> it's clearly necessary to be able to do low-level tests like the number
> colors, but I'd like to avoid it as much as possible. 

I agree.

Re: terminal capability querying

[Richard Stallman]

    One feature that I think would be useful and easy to implement would be
    the ability to query what capabilities (e.g., underlining, boldface) are
    supported when emacs is running on a tty.

Is there a way for Emacs to find this out?

Re: terminal capability querying

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     One feature that I think would be useful and easy to implement would be
>     the ability to query what capabilities (e.g., underlining, boldface) are
>     supported when emacs is running on a tty.
> 
> Is there a way for Emacs to find this out?

The face code obviously has to know which features a terminal has (and
which escape sequences control them) in order to display any given
attribute.

I'm merely suggesting a way for lisp code to get this information.

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche