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: Re: terminal capability querying Date: 20 Apr 2002 17:12:58 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: <873cxqrdo5.fsf@tc-1-100.kawasaki.gol.ne.jp> References: <87bscfqffo.fsf@tc-1-100.kawasaki.gol.ne.jp> <1349-Sat20Apr2002100838+0300-eliz@is.elta.co.il> 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 1019290525 27383 127.0.0.1 (20 Apr 2002 08:15:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2002 08:15:25 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16yq1l-00077Y-00 for ; Sat, 20 Apr 2002 10:15:25 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16yqLV-0008MN-00 for ; Sat, 20 Apr 2002 10:35:49 +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 16yq1Y-0004za-00; Sat, 20 Apr 2002 04:15:12 -0400 Original-Received: from smtp02.fields.gol.com ([203.216.5.132]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16ypzy-0004st-00; Sat, 20 Apr 2002 04:13:34 -0400 Original-Received: from tc-2-167.kawasaki.gol.ne.jp ([203.216.25.167] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 16ypzv-0007Cm-00; Sat, 20 Apr 2002 17:13:32 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id 238FE3075; Sat, 20 Apr 2002 17:12:58 +0900 (JST) Original-To: Eli Zaretskii System-Type: i686-pc-linux-gnu In-Reply-To: <1349-Sat20Apr2002100838+0300-eliz@is.elta.co.il> Original-Lines: 87 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:2822 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2822 "Eli Zaretskii" 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.