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: Sun, 6 Feb 2011 16:59:18 -0800 Message-ID: <1F1C73FF429943C6A882D1E03CC0BD23@us.oracle.com> References: <87oc6vm67v.fsf@stupidchicken.com><87vd12z77n.fsf@stupidchicken.com><87ipx289cu.fsf@nzebook.haselwarter.org> <1A6A06363E5F4274B2A00E2CA8A242D1@us.oracle.com> 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 1297040495 11323 80.91.229.12 (7 Feb 2011 01:01:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 01:01:35 +0000 (UTC) Cc: 'Philipp Haselwarter' , emacs-devel@gnu.org To: "'Tim Cross'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 07 02:01:31 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 1PmFTu-0002N2-EP for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 02:01:30 +0100 Original-Received: from localhost ([127.0.0.1]:36873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmFTt-0001GF-Rc for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2011 20:01:29 -0500 Original-Received: from [140.186.70.92] (port=43431 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmFTo-0001ET-A3 for emacs-devel@gnu.org; Sun, 06 Feb 2011 20:01:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmFTm-0005cV-TT for emacs-devel@gnu.org; Sun, 06 Feb 2011 20:01:24 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:43064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmFTm-0005cM-J9 for emacs-devel@gnu.org; Sun, 06 Feb 2011 20:01:22 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p1711FRV000651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 01:01:16 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p170G8Ii015559; Mon, 7 Feb 2011 01:01:14 GMT Original-Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 1027749841297040359; Sun, 06 Feb 2011 16:59:19 -0800 Original-Received: from dradamslap1 (/10.159.45.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 06 Feb 2011 16:59:18 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1A6A06363E5F4274B2A00E2CA8A242D1@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvEADd6GcHxcmvVR8+lgO8nrDVs6wACQO1gAJOASWA= X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D4F445B.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:135660 Archived-At: Tim pointed out the problem of faces that are not fully defined, in particular, for light and dark backgrounds (and for tty). He pointed to the need for the Emacs source code to define all faces fully so that they work, out-of-the-box, regardless of default background etc. And he pointed to the fact that, given such a basis, inheritance can carry the ball forward so that newly created faces are more likely, themselves, to be fully defined - without programmers needing to be face experts or jump through hoops. I agreed with Tim that it is good to fully define faces. Not doing so makes users customize more than they should need to. But I also explained why inheritance can be overkill as a solution to this problem. Inheritance should be used when the inheriting face is related to the inherited face - similar use/meaning/purpose. It should (generally) be avoided when there is no such relation. Inheritance does a good job of enforcing full face definition (given solid starting points). Can we get the same benefit some other way - a way that is not error prone by relying on programmers to copy full definitions by hand etc.? Sure - just use a copy instead of a pointer. What's bad about inheriting an unrelated fully-defined face is that customizing that face also changes the inheriting face. But that only happens because the new face always points to its ancestor for its attribute values. Why not introduce a new `defface' keyword `:copy-default'? It would define the new face with the same default attribute values as another face. A copy of those values (actually, of the attributes spec) would be made at `defface' time. The two faces would remain independent instead of being joined at the hip. Only the _default_ attribute values would be used; the current values of the reference face would have no effect at any time. If face `barred-foo' is unrelated to font-locking and strings, then instead of this (which is identical to the `defface' for `font-lock-doc-face): (defface barred-foo '((t :inherit font-lock-string-face)) "Face to use for foos that are barred." :group 'foobar) You would use this: (defface barred-foo '((t :copy-default font-lock-string-face)) "Face to use for foos that are barred." :group 'foobar) The new face `barred-foo' would have no relation to `font-lock-string-face'. A user could customize the latter without that change affecting the former. The result of the `defface' would be identical to this complex definition (taken from the definition of `font-lock-string-face'): (defface barred-foo '((((class grayscale) (background light)) (:foreground "DimGray" :slant italic)) (((class grayscale) (background dark)) (:foreground "LightGray" :slant italic)) (((class color) (min-colors 88) (background light)) (:foreground "VioletRed4")) (((class color) (min-colors 88) (background dark)) (:foreground "LightSalmon")) (((class color) (min-colors 16) (background light)) (:foreground "RosyBrown")) (((class color) (min-colors 16) (background dark)) (:foreground "LightSalmon")) (((class color) (min-colors 8)) (:foreground "green")) (t (:slant italic))) "Face to use for foos that are barred." :group 'foobar) Simple for even lazy programmers to use. Not so error-prone for eager programmers who might otherwise try to make such a copy by hand. Guaranteed to be as reasonable for all backgrounds and tty as is the tried-and-true `font-lock-string-face'. Anywhere you might use `:inherit' in a face definition you could use `:copy-default'. The same `defface' could use both `:inherit' and `:copy-default', to inherit some attribute values from one face and copy others (defaults) from another. We would encourage programmers to use `:inherit' when the new face (its use/meaning/purpose) is related to the referenced face - that is, when they want a change in the latter to be reflected in the former. (`font-lock-doc-face' inherits from `font-lock-string-face' because they are related.) We would encourage them to use `:copy-default' when the referenced face is unrelated and all they want to do is reuse its default-attributes spec. (`barred-foo' is about foos, not about font-locking or strings.) I expect that the latter case is more common than the former, but I could be wrong. New faces are often created together, as a group in some library, and these are often related in terms of use/purpose, so inheritance among them can make sense. But it is less likely that there is an existing face outside of that context whose use/meaning/purpose is related. IOW, I see inheritance as most useful within a library or among related libraries. It's worth quoting Tim again here. Having `:copy-default' in addition to `:inherit' would improve the solution, I think. T> I would not argue that inheritance is an ideal solution to T> this problem, However, I do think it can be part of the T> solution. Perhaps something along the lines of T> T> * Establish guidelines on how to use inheritance i.e. how to T> select which face to inherit from T> * Define a good (not too large) set of base faces. Existing T> font-lock faces may be sufficient, maybe not. Would need T> review. T> * Require all face definitions in core emacs packages to T> either fully define a face (i.e. definition for dark/light, T> tty, X mac ms etc) OR inherit from a base face (assuming T> all base faces are fully defined) T> * Add a section to the manual encouraging developers to T> either provide a fully defined face or inherit from a base T> face, but don't just define a single (usually) light T> background face T> T> The key here is that all faces in core emacs packages would T> end up with a fully defined face, either explicitly or via T> inherit.