Re: custom-themes BAD?

[Rainer M Krug <Rainer@krugs.de>]

[-- Attachment #1: Type: text/plain, Size: 7798 bytes --]

Dan Espen <despen@verizon.net> writes:

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

Now this is an important point and raises one question: there is a
load-theme function - but not an unload-theme which removes the
customizations done by the package? An author of a theme can not be
expected to undo all changes another theme might have done - but one
could expect a package author to provide a function which unloads the
theme and restores the theme used before, or simply reset to the default
values.

IMO, this is the problem with themes.

Cheers,

Rainer

>
> 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.
 Tue, 25 Feb 2014 13:03:49 -0500 (1 hour, 25 minutes, 11 seconds ago)
Organization: A noiseless patient Spider

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

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]