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 14:12:27 -0800 Message-ID: <8FB964FD62DD469C8CD10E63950ABBCA@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><858F4CEE5E7644D2AED7E6574802C6E8@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 1297118218 5579 80.91.229.12 (7 Feb 2011 22:36:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 22:36:58 +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 23:36:54 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 1PmZhV-0002ej-Um for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 23:36:54 +0100 Original-Received: from localhost ([127.0.0.1]:37670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmZUx-0003i4-CM for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 17:23:55 -0500 Original-Received: from [140.186.70.92] (port=42595 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmZM3-0007lz-O0 for emacs-devel@gnu.org; Mon, 07 Feb 2011 17:15:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmZLe-0002dJ-4S for emacs-devel@gnu.org; Mon, 07 Feb 2011 17:14:19 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:27117) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmZLd-0002d6-SI for emacs-devel@gnu.org; Mon, 07 Feb 2011 17:14:18 -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 p17MECmQ006000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Feb 2011 22:14:13 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p17MEAYj025476; Mon, 7 Feb 2011 22:14:11 GMT Original-Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 985786281297116750; Mon, 07 Feb 2011 14:12:30 -0800 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 07 Feb 2011 14:12:30 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvHDGd9SdTVdw+ASLeEPXobjTiuzgAAnCsQ X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D506EB3.0177: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:135696 Archived-At: T> I do see some possible implementation issues with T> the copy concept though. One problem could be T> determining when to do the copy. If I have face x T> and then define face y using your proposed copy T> semantics, how would you control when that copy occurs. I have not thought about implementation, nor will I really try to. ;-) I leave that to others more knowledgable. I did say what I thought was called for wrt copy time, however: copy when the `defface' with the `:copy-default' gets eval'd. Normally, that's at load time. And I did mention that only the default-attributes spec would be copied from the reference face - not the current values of its attributes: d> Why not introduce a new `defface' keyword `:copy-default'? d> It would define the new face with the same default d> attribute values as another face. A copy of those values d> (actually, of the attributes spec) would be made at d> `defface' time. d> Only the _default_ attribute values would be used; the d> current values of the reference face would have no effect d> at any time. IOW, this is a relation between two face _definitions_ (two `defface's), not between a `defface' and another face's current attribute values. Yes, this would likely require saving the referenced face spec in some form in the byte-compiled reference file, if that is not done already. And it would require copying that spec to the receiver at its `defface' eval time. [Another possibility is to allow copying when the receiver `defface' is byte-compiled, not just when it is eval'd. Dunno whether that would be a good idea or whether it could introduce differences (eval vs compile time).] No, I haven't tried to think this through, and especially not in terms of implementation. Just throwing the idea out there as food for thought by others more qualified. T> For example, if I customize face x, how will face y T> know the next time emacs is started to use the old T> values of face x and not the new customized values? See above. It would always look to face x's _definition_ (`defface'), not to its current attribute values. Customization of face x should have no effect. T> Somehow the defface would need to know to only copy T> the values from face x the first time it is defined/used T> i.e. from the first session that the face is used and T> to then keep those values for future sessions. Not sure I follow you. It would _never_ copy the current values. It would copy only the attributes spec from the reference face, that is, the part of the definition that is called for being copied. But yes, that spec would need to be available, in the source reference file (no problem) and in the byte-compiled reference file. A copy chain could presumably handled: if C copies from B which copies from A, then B's defface would be eval'd before C's defface. There might be some problems to work out, but I don't imagine they would be insurmountable. (But I know nothing about face implementation or byte-compilation.) T> Without this, you would simply have a form of delayed T> inheritance, which is likely going to be even more T> confusing that using normal inheritance as the change T> would be session dependent and time delayed. I don't follow. Again, it is only the default-attributes spec that would be copied, not the current attribute values. Access to that spec is all that is needed, I think. And it should be possible to provide that access through the byte-compiled reference file (as well as through the source reference file) - that is, the file whose `defface' is copied from. But again, I might well be missing a thing or two (or three...). T> This seems like a non-trivial modification to the T> defface mechanism as it introduces a new state/time T> dimension i.e. copy face x attributes unless face y T> attributes have already been copied in a previous session. The current attribute values would never be copied. Only the default-attributes spec would be copied - that is, the part of the reference face's definition (its `defface') that we specified to be copied. T> Maybe defface could have some type of 'initform' T> exstension that is used to configure the face if it T> has no custom setting. The result would need to be T> written to the custom-faces section so that it is T> only run once. I don't follow. But maybe you just misunderstood and thought I meant that the current attribute values would be copied?