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: Sat, 5 Feb 2011 14:09:28 -0800 Message-ID: References: <87oc6vm67v.fsf@stupidchicken.com><87vd12z77n.fsf@stupidchicken.com><87ipx289cu.fsf@nzebook.haselwarter.org> <877hdg3b4w.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1296943792 6628 80.91.229.12 (5 Feb 2011 22:09:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 5 Feb 2011 22:09:52 +0000 (UTC) Cc: emacs-devel@gnu.org, 'Philipp Haselwarter' To: "'Stephen J. Turnbull'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 05 23:09:48 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 1PlqKB-0004Ez-7V for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2011 23:09:47 +0100 Original-Received: from localhost ([127.0.0.1]:45037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PlqK6-000745-SQ for ged-emacs-devel@m.gmane.org; Sat, 05 Feb 2011 17:09:42 -0500 Original-Received: from [140.186.70.92] (port=46697 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PlqK1-00073q-H5 for emacs-devel@gnu.org; Sat, 05 Feb 2011 17:09:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PlqK0-0006lU-6S for emacs-devel@gnu.org; Sat, 05 Feb 2011 17:09:37 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:55068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PlqK0-0006lM-18 for emacs-devel@gnu.org; Sat, 05 Feb 2011 17:09:36 -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 p15M9TJd016886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Feb 2011 22:09:31 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 p15KFOv4012290; Sat, 5 Feb 2011 22:09:29 GMT Original-Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 982283321296943768; Sat, 05 Feb 2011 14:09:28 -0800 Original-Received: from dradamslap1 (/10.159.50.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 05 Feb 2011 14:09:28 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <877hdg3b4w.fsf@uwakimon.sk.tsukuba.ac.jp> Thread-Index: AcvEAk2JD0QuIyZdRAaGmsUGf/Ea5QAfs20A 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.0A090204.4D4DCA99.00C0: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:135622 Archived-At: S> I'm not saying that *all* faces should be derived from some S> base set, but Drew (and now you) seem to be saying that S> derivation from a base set is useless. The law of the S> excluded middle does not apply to all vs. none, you know. You are not saying *all*. And I am not saying *none* (or all vs none). Please drop the bugaboo strawman, Stephen. As a matter of fact your argument repeats mine; it does not counter it. S> The basic problem is that faces are not colors. Faces are S> not fonts. (Where have I heard this before? ;-) A face is S> a semantic component, intended to express meaning. S> Common meanings should have a common expression. d> Inheritance should be based on similarity (preferably set d> inclusion) of use (usage, use case, purpose), not just on d> similarity of face attributes. You used the word "semantic". Good. I might well have included that word in the parens. We both draw the same distinction between a face as only a combination of appearance attributes (no) and a face as having a purpose/meaning for particular contexts (yes). It is essentialy the same distinction that is made between physical markup and logical markup - between `italic' and `emphasis', for instance. We have both said that inheritance should, in general, be used for logical/usage/semantic entities, and *not* simply for combinations of attributes (physical/appearance). In my words: d> A new face should not inherit from face `region' just because d> its default attributes are the same as the default attributes d> of face `region', for example. The idea that inheritance should be based on similarity of usage/purpose/semantics rather than just similarity of value (e.g. color, size) implies that it is a mistake to have faces that are unrelated to font-locking be based on font-lock faces. A face whose purpose has something to do with comments could be based on `font-lock-comment-face', but a face such as `region' or `minibuffer-prompt' should probably not be based on it - there is too little logical/semantical/usage connection. Why does this matter? Coupling. Unwanted side effects for a descendent when you customize its ancestor. d> IMO, it makes sense for a face B to inherit from another face d> A _only_ when what is wanted is that customization of A d> automatically is reflected in B. When doing this, we should d> _always_ expect and assume that A will be customized by users. d> This is true no matter how "basic" A is. d> d> This is why (IMO) it does _not_ make sense in general for d> [all] faces to inherit from font-lock faces. S> Thus, for text modes there should be an "emphasis" face, and S> of course a "bogus whitespace" face for us pedants. In S> programming modes, "identifier" and "keyword" are common S> semantics. In compile modes, "info", "file", "position" S> (usually line number), "function", "error", and "warning" are S> common semantics. In shell modes, several levels of "prompt". S> Electric modes may want a "paren flash" face. Search modes a S> "hit" face and a "secondary hit" face. Again you support what I said. The important thing here is that you have grouped faces into contexts, groups based on usage/meaning. (Whether or not those particular groups are the best choices is beside the point.) The point is that inheritance makes sense within such a group (e.g., levels of prompt), and it makes a lot less sense (if any) across unrelated groups (e.g. prompt, search hit, and emphasis). How did this discussion start? Yidong seemed to be saying (possible misinterpretation, admittedly) that it would be good to get rid of duplicate face definitions, by which he apparently meant faces that have different names but the same attribute values. That is the issue. I argued that that would be misguided. Such faces typically are *not* duplicates. A face expresses meaning (a usage and context); it is not identical to its appearance. You put it this way: S> A face is a semantic component, intended to express meaning. S> Common meanings should have a common expression. I went a bit further and said that, in general, _only_ common meanings or use patterns should have a common expression. I have nothing against the examples of inheritance that you argued for. They are they same kinds of inheritance that I argued for. What I think is misguided is trying to boil things down across meaning groups (usage contexts) based on only equality of default attribute values. That's the issue. Looking for duplication of face definitions, and thus possible candidates for inheritance (factoring), should not be based on looking at their default attribute values. It should be based on what the faces represent, what they do, what they mean, how they are intended to be used. When duplicates of that kind are found, then yes, we can consider factoring out the duplication by using inheritance.