Gnus development mailing list
 help / color / mirror / Atom feed
From: Alex Schroeder <alex@emacswiki.org>
Subject: Re: defface/defcustom question
Date: Fri, 15 Aug 2003 14:07:17 +0200	[thread overview]
Message-ID: <87he4jt98q.fsf@emacswiki.org> (raw)
In-Reply-To: <84y8xwylvj.fsf@slowfox.is.informatik.uni-duisburg.de>

kai.grossjohann@gmx.net (Kai Großjohann) writes:

> Ah, I see.  An extra level of indirection can be good, I see now.

Well, it often feels like overengineering to me.  People really
understand face customization.

Consider how I customize the look of things.  I look at the buffer
and notice an ugly piece of text.  I try to discover the face used at
that point.  And then I customize it.  Straightforward. 

Now, how would I find out about the variable used for the indirection
we have?  I believe I would have to read the source for that.

Therefore I think that indirection via variables used to be a way to
keep the number of faces small.  Emacs Example: apropos-label-face's
value is italic.  In order to avoid creating a new apropos-label-face,
the author decided to reuse an existing face.  The same is true for
dired.  dired-font-lock-keywords contains lots of references to plain
font-lock faces such as font-lock-type-face, font-lock-constant-face,
etc.

The alternative is to create many new faces for each "item".  This is
why XEmacs has lots of dired faces.

So only one small unexplained item remains.  Why are there also variables
called font-lock-type-face and similar?  I think they are useless.
The reason is this: You cannot use M-x customize-option to change its
value.  You can use M-x customize-face to customize font-lock faces.

Therefore, having a variable font-lock-type-face pointing to the face
font-lock-type-face must be something old -- kept for backwards
compatibility.

For users, there should be only one thing to change.  And based on
how font-lock-type-face works, I suggest we allow users to customize
faces, not set variables.  This is also how I personally customize
Emacs, as I said at the beginning.

If at all, I therefore propose to remove the indirections via
variables.

Alex.
-- 
http://www.emacswiki.org/alex/
There is no substitute for experience.



      reply	other threads:[~2003-08-15 12:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-08 22:15 Jesper Harder
2003-08-09  1:54 ` Simon Josefsson
2003-08-09  9:55   ` Kai Großjohann
2003-08-09 11:32     ` Simon Josefsson
2003-08-09 13:13       ` Kai Großjohann
2003-08-09 15:45         ` Simon Josefsson
2003-08-09 16:43           ` Jesper Harder
2003-08-09 17:16           ` Alan Shutko
2003-08-09 18:05             ` Simon Josefsson
2003-08-09 18:44               ` Alan Shutko
2003-08-10 20:34                 ` Kai Großjohann
2003-08-25 14:41                 ` Per Abrahamsen
2003-08-10 20:33           ` Kai Großjohann
2003-08-12 11:53             ` Simon Josefsson
2003-08-14 21:23               ` Kai Großjohann
2003-08-15 12:07                 ` Alex Schroeder [this message]

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

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

  git send-email \
    --in-reply-to=87he4jt98q.fsf@emacswiki.org \
    --to=alex@emacswiki.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.
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 NNTP newsgroup(s).