Re: custom-themes BAD?

[Dan Espen <despen@verizon.net>]

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