[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: custom-themes BAD?
From: |
Dan Espen |
Subject: |
Re: custom-themes BAD? |
Date: |
Tue, 25 Feb 2014 13:03:49 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Drew Adams <drew.adams@oracle.com> writes:
>> 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'.
I know that, that was my point, they (or something like them)
should be available.
>> 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.
I'm only using GNUS as an example. Take a look at
manoj-dark-theme. You'll see the problem.
> 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.
If you use manoj-dark theme, then switch to another theme,
manoj will leave behind a huge number of it's customizations,
since other themes don't set as many fonts.
manoj-dark is 800 lines. Too many for the other theme creators
to deal with.
A theme should be able to change all the colors a user is
likely to see. A set of generic fonts that packages can
inherit from should solve the problem.
The font-lock faces are fine, they just don't go far enough.
--
Dan Espen
- custom-themes BAD?, Dan Espen, 2014/02/25
- RE: custom-themes BAD?, Drew Adams, 2014/02/25
- Message not available
- Re: custom-themes BAD?,
Dan Espen <=
- Re: custom-themes BAD?, Rainer M Krug, 2014/02/25
- Message not available
- Re: custom-themes BAD?, Dan Espen, 2014/02/25
- Re: custom-themes BAD?, Rainer M Krug, 2014/02/25
- Re: custom-themes BAD?, W . Greenhouse, 2014/02/25
- RE: custom-themes BAD?, Drew Adams, 2014/02/25