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: faces and face variables Date: Sat, 13 Sep 2008 15:43:09 -0700 Message-ID: <002c01c915f2$18dc9cf0$0200a8c0@us.oracle.com> References: <200809090636.m896acaT011007@sallyv1.ics.uci.edu><18630.36126.116571.102340@tfkp07.physik.uni-erlangen.de><200809091834.m89IYJrt004178@sallyv1.ics.uci.edu><18630.52279.410707.428217@tfkp07.physik.uni-erlangen.de><200809100554.m8A5sbLU020022@sallyv1.ics.uci.edu><18634.41341.360898.898779@tfkp07.physik.uni-erlangen.de><200809121750.m8CHoXar025729@sallyv1.ics.uci.edu><18634.45534.791696.614584@tfkp07.physik.uni-erlangen.de><200809130953.m8D9rEZC011379@sallyv1.ics.uci.edu><18635.58437.271555.722429@tfkp07.physik.uni-erlangen.de> <18636.5124.611868.27794@tfkp07.physik.uni-erlangen.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1221345805 27979 80.91.229.12 (13 Sep 2008 22:43:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2008 22:43:25 +0000 (UTC) Cc: 'Dan Nicolaescu' , emacs-devel@gnu.org To: "'Roland Winkler'" , "'Glenn Morris'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 14 00:44:21 2008 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 1Kedqm-0008Ok-Jb for ged-emacs-devel@m.gmane.org; Sun, 14 Sep 2008 00:44:20 +0200 Original-Received: from localhost ([127.0.0.1]:48157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kedpm-0003Pp-4D for ged-emacs-devel@m.gmane.org; Sat, 13 Sep 2008 18:43:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kedpg-0003OL-LO for emacs-devel@gnu.org; Sat, 13 Sep 2008 18:43:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kedpe-0003Mt-Uh for emacs-devel@gnu.org; Sat, 13 Sep 2008 18:43:12 -0400 Original-Received: from [199.232.76.173] (port=38542 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kedpe-0003Mf-Kc for emacs-devel@gnu.org; Sat, 13 Sep 2008 18:43:10 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]:18247) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KedpZ-0001YA-HM; Sat, 13 Sep 2008 18:43:05 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m8DMh13d010164; Sat, 13 Sep 2008 17:43:01 -0500 Original-Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id m8DMgxlX006730; Sat, 13 Sep 2008 16:43:00 -0600 Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Sep 2008 15:42:55 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckV1v2uqty0vQFdRCKMD8nqY1e8vwAGA6cw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <18636.5124.611868.27794@tfkp07.physik.uni-erlangen.de> X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-operating-system: by monty-python.gnu.org: GNU/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:103875 Archived-At: > I looked up defface in the elisp manual in order to find a hint. But > there was none. So I suggest to mention there (or include a link > pointing elsewhere) that such variables are deprecated. > > > > Font-lock also has such variables, and the code contains > > > the comment that these variables > > > > Don't use font-lock as an example, it's a law unto itself for > > historical reasons. > > As I said, the starting point for me was dired.el. Certainly, that > code has its own history. But the bottom line is that there is more > than one source for the "wrong inspiration" and it would be good if > at some prominent point it was stated clearly what today's > recommended strategy is (despite historical counter examples). > > Are there, besides font-lock and dired, other fossils in GNU emacs > that still use such variables? Dunno, maybe there are. If so, they should be removed. But I don't agree that face variables are or should be "deprecated" or that all uses of face variables are necessarily "fossils". Yes, the message to users should be that you normally do not want to create face variables - use faces directly instead. But that doesn't mean that face variables should never be used. This is what I wrote last February (thread "Default font 'default have no corresponding variable"): > > Maybe we should work harder to document the fact that we do not want > > such variables. Where would such info have reached you better? > > > > How about if we put comments in and among the variable > > definitions in font-lock.el saying not to imitate that practice. > > I think the place to discuss this is in the Elisp manual, in > one of the sections about faces. This is really about > understanding what a face is, IMO. > > FWIW, I have a slightly different take on the practice to > recommend and the reasons to give for that recommendation. > > I agree with the recommended practice of defining and using > faces, not face variables, in general - and I follow it. > However, I don't agree that the only case for defining and > using face variables is the legacy case of the font-lock code. > > The use case I see, which, again, is not the usual case, is > when you want to make it easy for code to temporarily use a > particular face. It is very easy for some code to dynamically > bind a face variable and cause subsequently executed code to > use that face. Getting the same effect with faces (without > a face variable) can make for uglier code, IMO. > > Just one opinion. I'm not interested in arguing about that. > I agree that we should make it clear that you generally > should not define face variables. And I think the place to > communicate that guideline is the Elisp doc, not just > comments in the code. FWIW, Richard replied: > I agree that this would be a good reason to have such a variable. > Whether there are such cases, I don't know. What's important, I think, is to propagate the general recommendation together with its rationale. That is, help users understand what faces are, which is what this is about. If all we provide is a catechism, then all we can expect is rote learning with little understanding. IOW, let's not confuse the effort to remove such fossils from the Emacs code with the idea that no one should ever use face variables. Use them in the (rare) cases where they are useful; don't use them otherwise.