From: Drew Adams <drew.adams@oracle.com>
To: Dan Espen <despen@verizon.net>, help-gnu-emacs@gnu.org
Subject: RE: custom-themes BAD?
Date: Tue, 25 Feb 2014 09:35:36 -0800 (PST) [thread overview]
Message-ID: <6db8b575-a9b3-471d-8007-765fbdc8b9df@default> (raw)
In-Reply-To: <ic1tyrdsrh.fsf@home.home>
> When we get to packages like gnus, gnus goes ahead and
> defines it's own faces:
>
> gnus-cite-attribution-face
> gnus-cite-face-1
> gnus-cite-face-2
> gnus-cite-face-3
> gnus-cite-face-4
> gnus-cite-face-5
> gnus-cite-face-6
> gnus-cite-face-7
> gnus-cite-face-8
> gnus-cite-face-9
> gnus-cite-face-10
> gnus-cite-face-11
> gnus-emphasis-bold
> gnus-emphasis-bold-italic
>
> That's the problem, there should be font-lock faces like:
>
> font-lock-bold,
> font-lock-level-1 thru 12,
> font-lock-large-1,,,
> font-lock-blue...
> font-lock-reverse
Those are not existing font-lock faces, AFAIK. They are certainly
not defined by library `font-lock.el'.
> and so on.
>
> All the packages should be using font-lock-* faces as far as
> possible. Then the themes can all set the same set of faces
> much more easily.
I cannot speak to whether it is appropriate for Gnus to define
faces for its use here or whether it should instead just use
common font-lock faces instead. I do not use Gnus.
That kind of question needs to be decided on a case-by-case
basis. I only want to add here that it is NOT the case that
libraries "should" reuse font-lock faces, in general. They
should use font-lock faces when that makes sense, and not
otherwise.
The advantage of reusing a common face is the same as the
disadavantage: change it once here and it gets changed everywhere
it is used. That makes some things easier and others more
difficult.
What is especially pernicious, IMO, is *hard-coding* the use
of a particular face, rather than providing a new face whose
default appearance *inherits* from that face.
That makes it unnecessarily difficult for a user to customize
the use of that particular highlighting.
E.g., a given library `foo.el' might well define a face
`foo-emphasis', which might inherit its default appearance from
the basic face `italic'. It is then easy for a user to
customize the appearance of that Foo highlighting without
affecting use of face `italic' throughout Emacs.
If, instead, `foo.el' just uses face `italic', then the user
loses flexibility: s?he must change the appearance everywhere
or nowhere.
If a library defines a new face, but inherits its default
appearance from another face, a user can customize either the
parent face or the child. In the former case, the result is
the same as in the hard-coded context: customize once to
change the appearance everywhere (everywhere that inherits).
So you really lose nothing by defining a library-specific face.
Other people, including some Emacs maintainers, disagree.
The result is that we still have some hard-coded uses of general
faces, rather than letting users decide easily.
With no knowledge of Gnus and its faces, I'll ask: just what
is the problem that you are trying to raise here, wrt custom
themes? Is it that lots of faces means theme size is too large?
IOW, it's not clear to me what your point is.
next prev parent reply other threads:[~2014-02-25 17:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 17:08 custom-themes BAD? Dan Espen
2014-02-25 17:22 ` Joost Kremers
2014-02-25 17:38 ` E Sabof
2014-02-25 17:54 ` Dan Espen
[not found] ` <mailman.16024.1393350344.10748.help-gnu-emacs@gnu.org>
2014-02-25 18:06 ` Dan Espen
2014-02-25 17:35 ` Drew Adams [this message]
[not found] ` <mailman.16021.1393349758.10748.help-gnu-emacs@gnu.org>
2014-02-25 18:03 ` Dan Espen
2014-02-25 19:33 ` Rainer M Krug
[not found] ` <mailman.16038.1393356841.10748.help-gnu-emacs@gnu.org>
2014-02-25 19:48 ` Dan Espen
2014-02-25 20:04 ` Rainer M Krug
2014-02-25 21:05 ` W. Greenhouse
2014-02-25 22:19 ` Drew Adams
[not found] <<ic1tyrdsrh.fsf@home.home>
[not found] ` <<slrnlgpkad.3j2.joost.m.kremers@j.kremers4.news.arnhem.chello.nl>
2014-02-25 17:45 ` Drew Adams
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=6db8b575-a9b3-471d-8007-765fbdc8b9df@default \
--to=drew.adams@oracle.com \
--cc=despen@verizon.net \
--cc=help-gnu-emacs@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.
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).