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: Simplification of faces Date: Mon, 1 Oct 2007 11:18:02 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1191262867 5126 80.91.229.12 (1 Oct 2007 18:21:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 1 Oct 2007 18:21:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 01 20:21:04 2007 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.50) id 1IcPt7-0002Ad-JD for ged-emacs-devel@m.gmane.org; Mon, 01 Oct 2007 20:21:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcPt3-0004P0-9R for ged-emacs-devel@m.gmane.org; Mon, 01 Oct 2007 14:20:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IcPrs-0003rx-OP for emacs-devel@gnu.org; Mon, 01 Oct 2007 14:19:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IcPrr-0003qW-4S for emacs-devel@gnu.org; Mon, 01 Oct 2007 14:19:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IcPrq-0003qO-Q8 for emacs-devel@gnu.org; Mon, 01 Oct 2007 14:19:42 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IcPrm-0000um-CH; Mon, 01 Oct 2007 14:19:38 -0400 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l91IJZEW032506; Mon, 1 Oct 2007 13:19:36 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l916qDhc020093; Mon, 1 Oct 2007 12:19:35 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3258828361191262679; Mon, 01 Oct 2007 11:17:59 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 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:80106 Archived-At: > > I am thinking of essentially eliminating the face > > attributes as a way to control what a face looks like. > > Programs would use only `defface' and `face-spec-set'. > > What about `modify-face'? > > `modify-face' is another interface to `set-face-attribute'. Under > this proposal, we would get rid of both. Could you give a simple example of how a current use of `modify-face' would be replaced with a call to `face-spec-set' or `defface' in your proposal? I have nothing against doing things differently; I just want to know whether and how I can still do what I do now (in some way). What I do now is change only selected attributes of a face, leaving the rest as they were. > I'm not too clear on `face-spec-set'. Is what it does now is > replace only those attributes that are included in its SPEC arg, > leaving the others alone? > > That is what I thought yesterday from reading its code, but I see that > in fact it calls `face-spec-reset-face'. So it already does totally > replace any other settings for that face. That's what I thought. See my proposal for `set-face', based on that understanding. AFAICT, `face-spec-set' completely redefines an existing face, but it cannot be used to create a new face. For variables, we have `defvar' and `defcustom' that are analogous to `defface', but we also have `setq', which is not analogous to `face-spec-set', AFAICT: `setq' creates a variable if it did not already exist. What I was asking for was an equivalent of `setq' for faces. Perhaps `face-spec-set' could be redefined to do that, or a new function `set-face' could be defined to do that. > So this proposal therefore reduces to eliminating the > `set-face-attribute' level of interface for controlling faces. > > I hope that I will at least be able to still use > `modify-face'. > > Why do you want to use `modify-face'? To modify a face. ;-) To modify it only partly - only some attributes. I have nothing against doing that some other way, but how to do that with `face-spec-set' is not clear to me. Suppose, for instance, that I just want to set (e.g. replace) the foreground color. How would I call `face-spec-set' to do that (and still leave the rest of the face as it was defined?