From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: terminal capability querying Date: 20 Apr 2002 11:20:11 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <87bscfqffo.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019269290 10625 127.0.0.1 (20 Apr 2002 02:21:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2002 02:21:30 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16ykVG-0002lG-00 for ; Sat, 20 Apr 2002 04:21:30 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16ykot-0000Wi-00 for ; Sat, 20 Apr 2002 04:41:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16ykV2-0006eN-00; Fri, 19 Apr 2002 22:21:16 -0400 Original-Received: from smtp02.fields.gol.com ([203.216.5.132]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16ykUc-0006cU-00; Fri, 19 Apr 2002 22:20:50 -0400 Original-Received: from tc-2-214.kawasaki.gol.ne.jp ([203.216.25.214] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 16ykUa-0004LF-00; Sat, 20 Apr 2002 11:20:48 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id DFAEB3075; Sat, 20 Apr 2002 11:20:11 +0900 (JST) Original-To: emacs-devel@gnu.org System-Type: i686-pc-linux-gnu Original-Lines: 71 X-Abuse-Complaints: abuse@gol.com Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2817 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2817 [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)