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: Mon, 7 Feb 2011 06:09:34 -0800 Message-ID: <858F4CEE5E7644D2AED7E6574802C6E8@us.oracle.com> References: <87oc6vm67v.fsf@stupidchicken.com><87vd12z77n.fsf@stupidchicken.com><87ipx289cu.fsf@nzebook.haselwarter.org><1A6A06363E5F4274B2A00E2CA8A242D1@us.oracle.com><1F1C73FF429943C6A882D1E03CC0BD23@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 1297088793 27746 80.91.229.12 (7 Feb 2011 14:26:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 14:26:33 +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 15:26:28 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 1PmS2o-0006F2-HL for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 15:26:22 +0100 Original-Received: from localhost ([127.0.0.1]:58725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmS2n-0006d2-NZ for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 09:26:21 -0500 Original-Received: from [140.186.70.92] (port=38249 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmRnM-00076k-C9 for emacs-devel@gnu.org; Mon, 07 Feb 2011 09:10:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmRnL-0005CX-6U for emacs-devel@gnu.org; Mon, 07 Feb 2011 09:10:24 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:28834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmRnL-0005CJ-1I for emacs-devel@gnu.org; Mon, 07 Feb 2011 09:10:23 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p17EAFXo021414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 14:10:17 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p17EADOa001784; Mon, 7 Feb 2011 14:10:14 GMT Original-Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 1029654291297087774; Mon, 07 Feb 2011 06:09:34 -0800 Original-Received: from dradamslap1 (/10.159.54.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Feb 2011 06:09:33 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvGZqsdlZJIM2EaTFK8PYyuN+NE9wAZ+Qhw X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4D4FFD47.0070: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:135677 Archived-At: T> Ignoring implementation issues, your suggestion appears to T> meet the main objective i.e. making it easier for programmers T> to do the right thing and have fully defined faces without T> having to jump through all the hoops. I would agree that it is T> a better solution than using inheritance with semantically T> unrelated parents as it does appear to provide a solution that T> does not compromise the strict form of preferred inheritance T> and a way to improve the quality of default face values. T> T> I would suggest that in addition to such enhancements to defface, T> we need to provide guidelines in the manual on how to use T> inheritance and copy and would go further and argue that for T> semantically related faces, inheritance *should* be used to help T> enhance consistency and allow users to customize a semantic T> 'class' in one go. Yes to guidelines in the manual and yes to encouraging inheritance among faces with similar meaning/use. As I said: d> We would encourage programmers to use `:inherit' when the d> new face (its use/meaning/purpose) is related to the d> referenced face - that is, when they want a change in the d> latter to be reflected in the former. d> We would encourage them to use `:copy-default' when the d> referenced face is unrelated and all they want to do is d> reuse its default-attributes spec. We would encourage them to use one or the other, to get full face definitions able to handle different backgrounds etc. And we would explain when it can be good to use one vs the other. We would also say why full definitions are important, and perhaps use an example to point out characteristics of a full definition.