From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.devel Subject: Re: About the :distant-foreground face attribute Date: Thu, 9 Jan 2014 09:39:43 -0800 Message-ID: References: <87bnzo9cja.fsf@gnu.org> <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> <874n5f3162.fsf@gnu.org> <83fvozf86g.fsf@gnu.org> <87r48javwe.fsf@gnu.org> <83bnzmfjxe.fsf@gnu.org> <87bnzlyvwb.fsf@gnu.org> <83zjn5cch3.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1389289224 23530 80.91.229.3 (9 Jan 2014 17:40:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 17:40:24 +0000 (UTC) Cc: Chong Yidong , =?ISO-8859-1?Q?Jan_Dj=E4rv?= , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 09 18:40:30 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1Jam-0000X5-Ta for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 18:40:29 +0100 Original-Received: from localhost ([::1]:53314 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Jam-0005ed-I5 for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 12:40:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Jaf-0005dX-2g for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:40:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1Jaa-0001Rn-7L for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:40:21 -0500 Original-Received: from mail-wg0-f45.google.com ([74.125.82.45]:33319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Jaa-0001RX-0c for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:40:16 -0500 Original-Received: by mail-wg0-f45.google.com with SMTP id y10so3115235wgg.24 for ; Thu, 09 Jan 2014 09:40:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=q/l1McMV76scrmOYGtayNbf+S1n1SMIVUqVqd6U2D3w=; b=ZVJIb5VcUxKEmZSqQBr2cVDirHt2v1rkvdimIFh9n0QiArmCKVJNPG/BPittcZYjgo E5xw8Wgg1FK2WKwtjjY9oOdeb6RGPXRUTJ1npnzftLU27Yydj1Ae6a7XxMB5QplRaI5a LSFrUX3OOlvzhawQAIoQYqHKgejFBG+J5RnZfpPwAHhabLKvQBXHKN+nOnWaxKVE5OQB 5GgyiUHYwxawYS41gsS5pumpINsrmpxNgjrlo92tBsnxINSInJX4lc/H6UDQej7W4HQa YjEVxVVdh6IUQyOuN2Hth3g2dkEfvQgwvIq8pmcrwVNjo9Kau8N1JrQ42cWypMsYFyTD eYMA== X-Gm-Message-State: ALoCoQnr3A1EWxtav0x342TvF5Te2yItbtFt1x/Y4a34Hlk0a7DxurJVLtVCpn2fmrGA2GzCnnos X-Received: by 10.180.89.68 with SMTP id bm4mr27982293wib.0.1389289214937; Thu, 09 Jan 2014 09:40:14 -0800 (PST) Original-Received: by 10.194.165.226 with HTTP; Thu, 9 Jan 2014 09:39:43 -0800 (PST) In-Reply-To: <83zjn5cch3.fsf@gnu.org> X-Google-Sender-Auth: 8AX9UujGfs1Cn6Xt05qziD7tOxw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.45 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167949 Archived-At: On Thu, Jan 9, 2014 at 9:05 AM, Eli Zaretskii wrote: >> From: Chong Yidong >> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org >> Date: Fri, 10 Jan 2014 00:15:00 +0800 >> >> Eli Zaretskii writes: >> >> >> The analogy would be if there was a :low-color-foreground face attribute >> >> which would override :foreground on low-color displays. That would be >> >> ugly, as I hope you agree. >> > >> > I'm not sure I see the ugliness, please elaborate. >> >> One face attribute should govern one aspect of how the face is >> displayed. In some cases, it may be hard to avoid having multiple >> attributes with overlapping effects, but the results are not pretty. >> For example, the interactions between :family, :foundry and :font have >> been a source of annoyance over the years. Introducing another such >> situation should, in my view, be avoided as far as possible. >> >> An example of a face attribute that handles things right is the :height >> attribute. An absolute height is given by an integer, while a relative >> height can be specified by a float. Allowing both in a single attribute >> is good, because absolute height and the relative height are just >> different ways to specify height. We don't have a :height and a >> separate :relative-height attribute. > > If you are arguing for a change in the syntax of :foreground such that > it could convey the information about both the "normal" color, and the > alternate color to be used when the background is too similar to that > "normal" color, then I agree it will probably be a nicer and cleaner > feature. But that means :foreground will no longer be a simple > string, but some more complex data structure, e.g. a list. > >> If I cannot convince anyone that there is a problem here, then forget >> it. > > Don't give up just yet ;-) > > The solution should be able to cope with the need to dynamically > decide which color is used as a foreground, based on the current > background. It also needs to support the possibility that a face will > want to force use of a specific fixed foreground color, regardless of > the background. (Jan, did I miss some additional requirements?) If > you can propose a cleaner solution that satisfies these requirements, > please do, and let's discuss that. Instead of explicitly specifying alternative foreground colors, whether by introducing a new face attribute or extending the current :foreground attribute, perhaps we could introduce a new `minimum-color-distance' user preference that would be used something like this: (defun choose-foreground-color (fg bg minimum-color-distance) (if (or (> (color-distance fg bg) minimum-color-distance) ;; ^^^ foreground and background are sufficiently different (= fg bg)) ;; ^^^ special case for text invisibility via fg==bg fg ;; preferred foreground color is ok; use it ;; otherwise, compute new foreground color -- not necessarily ;; via logxor but somehow guaranteed to be distant from bg (cl-mapcar 'logxor fg bg))) Though such computed colors are likely to be ugly, clash with color themes, etc. this approach is less invasive than the others being discussed and I think it accomplishes the primary goal of ensuring that bad combinations of foreground and background colors cannot render text illegible. Josh