[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
terminal capability querying
terminal capability querying
20 Apr 2002 11:20:11 +0900
[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:
'(((capable :slant italic) :slant italic)
((capable :underline) :underline t)
(t :slant italic))
"Basic italic font."
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
Saa, shall we dance? (from a dance-class advertisement)
Re: terminal capability querying, Richard Stallman, 2002/04/21
- terminal capability querying,
Miles Bader <=