From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: terminal capability querying Date: Sat, 20 Apr 2002 12:31:15 +0300 Sender: emacs-devel-admin@gnu.org Message-ID: <3776-Sat20Apr2002123114+0300-eliz@is.elta.co.il> References: <87bscfqffo.fsf@tc-1-100.kawasaki.gol.ne.jp> <1349-Sat20Apr2002100838+0300-eliz@is.elta.co.il> <873cxqrdo5.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019295748 31781 127.0.0.1 (20 Apr 2002 09:42:28 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2002 09:42:28 +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 16yrO0-0008GU-00 for ; Sat, 20 Apr 2002 11:42:28 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16yrhm-0001qr-00 for ; Sat, 20 Apr 2002 12:02:54 +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 16yrNi-0006Ed-00; Sat, 20 Apr 2002 05:42:10 -0400 Original-Received: from frigg.inter.net.il ([192.114.186.16]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16yrMS-00066o-00; Sat, 20 Apr 2002 05:40:52 -0400 Original-Received: from zaretsky ([80.230.2.40]) by frigg.inter.net.il (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id BIO13711; Sat, 20 Apr 2002 12:40:48 +0300 (IDT) Original-To: miles@gnu.org X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9 In-Reply-To: <873cxqrdo5.fsf@tc-1-100.kawasaki.gol.ne.jp> (message from Miles Bader on 20 Apr 2002 17:12:58 +0900) 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:2823 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2823 > From: Miles Bader > 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.