From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: RE: Eliminating a couple of independent face definitions Date: Fri, 04 Feb 2011 09:18:39 +0900 Message-ID: <877hdg3b4w.fsf@uwakimon.sk.tsukuba.ac.jp> 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 X-Trace: dough.gmane.org 1296779274 18545 80.91.229.12 (4 Feb 2011 00:27:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 4 Feb 2011 00:27:54 +0000 (UTC) Cc: emacs-devel@gnu.org, 'Philipp Haselwarter' To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 04 01:27:50 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 1Pl9Wf-0006V6-Bj for ged-emacs-devel@m.gmane.org; Fri, 04 Feb 2011 01:27:50 +0100 Original-Received: from localhost ([127.0.0.1]:44263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl9We-0001NJ-2N for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2011 19:27:48 -0500 Original-Received: from [140.186.70.92] (port=47133 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl9WT-0001LQ-Ex for emacs-devel@gnu.org; Thu, 03 Feb 2011 19:27:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pl9WP-0006zl-9P for emacs-devel@gnu.org; Thu, 03 Feb 2011 19:27:34 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:55306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pl9WO-0006xj-Kw for emacs-devel@gnu.org; Thu, 03 Feb 2011 19:27:33 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3B45997066E; Fri, 4 Feb 2011 09:27:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B121B1A300D; Fri, 4 Feb 2011 09:18:39 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:135543 Archived-At: Drew Adams writes: > 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 - Sure, it's a help with customization, but it does not address the basic problem. > I'd be interested in hearing more arguments in favor of faces inheriting from > faces (e.g. "basic" faces). The basic problem is that faces are not colors. Faces are not fonts. (Where have I heard this before? ;-) A face is a semantic component, intended to express meaning. Common meanings should have a common expression. Thus, for text modes there should be an "emphasis" face, and of course a "bogus whitespace" face for us pedants. In programming modes, "identifier" and "keyword" are common semantics. In compile modes, "info", "file", "position" (usually line number), "function", "error", and "warning" are common semantics. In shell modes, several levels of "prompt". Electric modes may want a "paren flash" face. Search modes a "hit" face and a "secondary hit" face. For many simple modes, such basic faces will be enough, and used as is. However, modes of medium complexity may want to inherit in order to allow customization of that mode without affecting others, especially modes with lots of faces where customization of one face may collide with the basic definition of another, and the user prefers to change the second face in the mode where it collides but not elsewhere. This has happened to me occasionally, though by now most of my customizations are inches thick in moss. It might also be useful to have semantically derived faces, so that "strong emphasis" (introduced to support markup modes like HTML) would derive from "emphasis" (but this is speculative). On the same theme, "keyword" might derive from "identifier".