From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Eliminating a couple of independent face definitions Date: Thu, 3 Feb 2011 11:10:43 -0800 Message-ID: References: <87oc6vm67v.fsf@stupidchicken.com><87vd12z77n.fsf@stupidchicken.com> <87ipx289cu.fsf@nzebook.haselwarter.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1296760305 10454 80.91.229.12 (3 Feb 2011 19:11:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 3 Feb 2011 19:11:45 +0000 (UTC) To: "'Philipp Haselwarter'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 03 20:11:41 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Pl4aT-0006pQ-Pa for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2011 20:11:40 +0100 Original-Received: from localhost ([127.0.0.1]:53035 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl4aO-0005wQ-Kd for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2011 14:11:20 -0500 Original-Received: from [140.186.70.92] (port=49330 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl4aC-0005ox-1g for emacs-devel@gnu.org; Thu, 03 Feb 2011 14:11:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pl4Zz-00018f-Ms for emacs-devel@gnu.org; Thu, 03 Feb 2011 14:10:56 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:17765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pl4Zz-00017t-HV for emacs-devel@gnu.org; Thu, 03 Feb 2011 14:10:55 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p13JAlLh019258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Feb 2011 19:10:48 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p13FMIQ2018384; Thu, 3 Feb 2011 19:10:46 GMT Original-Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 1020918511296760243; Thu, 03 Feb 2011 11:10:43 -0800 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Feb 2011 11:10:43 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ipx289cu.fsf@nzebook.haselwarter.org> Thread-Index: AcvDJ6/B9fuoJnDGTbKHeJfCZIXM4gApd+Ig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D4AFDB7.000D:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:135513 Archived-At: > As Drew said, faces need to make sense in their context. > > I just spent some time picking sensible faces from the font-lock-* > palette for dired+, which by default defines its own static faces. That's my fault. I defined the default Dired+ face colors only for light backgrounds. I DTRT for Icicles long ago, but I never got around to doing the same for Dired+. I've done that now, thanks to your reminder. (However, I intentionally do not use face inheritance - see below.) FWIW, for this I simply use the complements of the light-background default colors as the dark-background colors. That is not necessarily ideal, but it at least is reasonable and consistent. It is also very quick to do, given some code (e.g. hexrgb.el or palette.el) that quickly gives you color complements. Such defaulting could presumably even be built-in (optionally). For example, we could allow a dark-background setting to be just a symbol `complement' or `:complement', which would mean to pick up the `t' setting or the light-background setting (if present) and use its complement. Likewise for light-background setting - whatever is defined would be used for the other setting, as a complement. That way a coder could provide a minimal face definition and still get something reasonable for other background modes. This could obviously be made more sophisticated, but any such feature could be an improvement, helping with the problem of coders being lazy and just defining defaults for one background mode (e.g. light in my case; that is, I designed for light but defined it as `t', meaning all). ---- Wrt face inheritance - Faces are customizable - they are just like user options. In particular, faces are _not colors_ and faces are _not constants_. Color names and RGB hex codes are essentially constants (even if they can appear slightly different on different systems etc.). IMO, it makes sense for a face B to inherit from another face A _only_ when what is wanted is that customization of A automatically is reflected in B. When doing this, we should _always_ expect and assume that A will be customized by users. This is true no matter how "basic" A is. This is why (IMO) it does _not_ make sense in general for faces to inherit from font-lock faces. A user will want to customize a font-lock face in order to affect the appearance of _font-locking_, typically in code. It does not generally make sense for a non-font-lock face to automatically become affected by such customization. Example: basing a Dired face on a font-lock face would be perverted (IMO). My guess is that people who are thinking that inheritance from a few (or even many) "basic" faces (font-lock or others) is a good idea are not taking customization of such basic faces by users into account. IOW, they are not considering them as _faces_, but rather as constants (e.g. as colors or color combos). There would be nothing wrong with defining some _constants_ from which faces could inherit - not defface but something else that indicates the intention of not being customized. Nothing wrong with coming up with such "basic faces" that would never be customized. But what would that mean? In this case what is important is not the _usage_ of the face (it cannot be; that cannot be known), but just its attributes: colors etc. IOW, instead of a basic face `highlight' intended for highlighting we would have basic faces whose names reflect only their appearance: `red-foreground-bold-boxed' etc. But though there would be nothing wrong with defining such constant faces, it would be truly silly. There is no sense defining such attribute combinations - no sense defining (uncustomizable) faces for this. We already have such constants: the colors themselves (names and #RGB hex codes). And numbers for weights etc. Defining combinations as constants makes little sense. It is proper to base defface definitions on such constants, but not (in general) on other faces. The only time the latter is appropriate (IMO) is when we really want customizing face A to affect face B which inherits from A. You do not, I think, want a Dired face to change just because a user tweaks a font-lock face to make code comments stand out differently. The real problem that I'm guessing motivates the (misguided) attempts to base faces upon each other is that too often the default values of faces are not defined well enough (see the Dired+ mea culpa above). Too often too little effort is devoted to defining the default attributes. The other problem that has been mentioned is being able to apply different themes and have the result be more or less reasonable across sets of faces. I think that this is not a fundamental problem but is only derivative from not having good defaults. Just having reasonable default values that cover both light and dark backgrounds will go a long way toward eliminating this problem, I expect. In addition, tools that let users easily change whole sets of faces together, incrementally, can help. Do Re Mi offers some help in this way, and other such tools can be envisaged. Example: command `doremi-all-faces-fg+' lets you incrementally modify all face foregrounds at once (hue, saturation, brightness, red, green, and/or blue). Obviously such a command is limited, but in combination with others it can be a real help for customizing - and even for defining themes. I'd be interested in hearing more arguments in favor of faces inheriting from faces (e.g. "basic" faces). So far it all seems misguided to me, but perhaps I'm missing a thing or two. Please be clear about (a) the _problems_ you are trying to solve this way, and (b) _how_ you think face inheritance can solve them.