unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Roland Winkler'" <Roland.Winkler@physik.uni-erlangen.de>,
	"'Glenn Morris'" <rgm@gnu.org>
Cc: 'Dan Nicolaescu' <dann@ics.uci.edu>, emacs-devel@gnu.org
Subject: RE: faces and face variables
Date: Sat, 13 Sep 2008 15:43:09 -0700	[thread overview]
Message-ID: <002c01c915f2$18dc9cf0$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <18636.5124.611868.27794@tfkp07.physik.uni-erlangen.de>

> 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.






  reply	other threads:[~2008-09-13 22:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200809090636.m896acaT011007@sallyv1.ics.uci.edu>
     [not found] ` <18630.36126.116571.102340@tfkp07.physik.uni-erlangen.de>
     [not found]   ` <200809091834.m89IYJrt004178@sallyv1.ics.uci.edu>
     [not found]     ` <18630.52279.410707.428217@tfkp07.physik.uni-erlangen.de>
     [not found]       ` <200809100554.m8A5sbLU020022@sallyv1.ics.uci.edu>
     [not found]         ` <18634.41341.360898.898779@tfkp07.physik.uni-erlangen.de>
     [not found]           ` <200809121750.m8CHoXar025729@sallyv1.ics.uci.edu>
     [not found]             ` <18634.45534.791696.614584@tfkp07.physik.uni-erlangen.de>
     [not found]               ` <200809130953.m8D9rEZC011379@sallyv1.ics.uci.edu>
2008-09-13 16:03                 ` faces and face variables Roland Winkler
2008-09-13 18:09                   ` Glenn Morris
2008-09-13 19:27                     ` Roland Winkler
2008-09-13 22:43                       ` Drew Adams [this message]
2008-09-14 17:02                         ` Miles Bader
2008-09-14 19:04                           ` Drew Adams
     [not found] ` <18775.34703.848628.238267@tfkp04.physik.uni-erlangen.de>
2008-12-29  6:33   ` Proced's display/handling of process trees: request for feedback Roland Winkler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='002c01c915f2$18dc9cf0$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=Roland.Winkler@physik.uni-erlangen.de \
    --cc=dann@ics.uci.edu \
    --cc=emacs-devel@gnu.org \
    --cc=rgm@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).