RE: custom-themes BAD?

RE: custom-themes BAD?

[Drew Adams]

> > 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.
> 
> Better yet, packages should define their own faces but use the :inherit
> property to derive them from Emacs' standard faces. That way, users can
> customize faces in some mode/package and use the default ones in others,
> if they prefer.

Exactly.  And it's not just "better *yet*", as if the first
suggestion itself represented some improvement but not the
best improvement.  The first approach is generally misguided, IMO.

It is simply not the case that "all packages should be using
font-lock-* faces as far as possible."  That is bad advice, IMO.
Package designers should use their heads, keeping the package users
foremost in mind.

I also wonder about this part:

> > Then the themes can all set the same set of faces much more
> > easily.

Why should I care how easy it is for "themes to set" the same
set of faces?  What I care about is how easy it is for users
to customize a set of faces.  And for users of themes to control
them.

Now if it is the case that custom themes are "BAD", in that there
is no easy way to customize a set of faces across multiple
themes, then that would be something missing in the design of
custom themes.  That would not surprise me, but I'm no expert on
custom themes.

custom-themes BAD?

[Dan Espen]

Custom-themes look to me like they are BAD (Broken As Designed).

I'm running Emacs 24.3.1 here and this is what I see in the themes
directory:

  5089 Jan  1  2013 adwaita-theme.el
  6434 Jan  1  2013 deeper-blue-theme.el
  6048 Jan  1  2013 dichromacy-theme.el
  2885 Jan  1  2013 light-blue-theme.el
 40948 Jan  1  2013 manoj-dark-theme.el
  5167 Jan  1  2013 misterioso-theme.el
  7720 Jan  1  2013 tango-dark-theme.el
  7080 Jan  1  2013 tango-theme.el
  3550 Jan  1  2013 tsdh-dark-theme.el
  3357 Jan  1  2013 tsdh-light-theme.el
  3680 Jan  1  2013 wheatgrass-theme.el
  5165 Jan  1  2013 whiteboard-theme.el
  5287 Jan  1  2013 wombat-theme.el

Notice that one theme, (manoj-dark) is way bigger than
any of the other themes.

Looking in these files, I see that each theme designer
decides which Emacs packages he's going to support.
The more packages supported, the bigger the theme file.

I think the fault lies with the base package for fonts
Emacs defines.  The basic faces were the font-lock faces,
builtin, constant, preprocessor, etc.

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

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.


-- 
Dan Espen

Re: custom-themes BAD?

[Joost Kremers]

Dan Espen wrote:
> 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.

Better yet, packages should define their own faces but use the :inherit
property to derive them from Emacs' standard faces. That way, users can
customize faces in some mode/package and use the default ones in others,
if they prefer.


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: custom-themes BAD?

[E Sabof]

Joost Kremers <joost.m.kremers@gmail.com> writes:

> Better yet, packages should define their own faces but use the :inherit
> property to derive them from Emacs' standard faces. That way, users can
> customize faces in some mode/package and use the default ones in others,
> if they prefer.

+1

Re: custom-themes BAD?

[Dan Espen]

Joost Kremers <joost.m.kremers@gmail.com> writes:

> Dan Espen wrote:
>> 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.
>
> Better yet, packages should define their own faces but use the :inherit
> property to derive them from Emacs' standard faces. That way, users can
> customize faces in some mode/package and use the default ones in others,
> if they prefer.

I was not aware of any :inherit property, but that sounds perfect.

Still there should be enough faces defined that gnus, and all the
other packages can do there thing.

-- 
Dan Espen

Re: custom-themes BAD?

[Dan Espen]

Drew Adams <drew.adams@oracle.com> writes:

>> > 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.
>> 
>> Better yet, packages should define their own faces but use the :inherit
>> property to derive them from Emacs' standard faces. That way, users can
>> customize faces in some mode/package and use the default ones in others,
>> if they prefer.
>
> Exactly.  And it's not just "better *yet*", as if the first
> suggestion itself represented some improvement but not the
> best improvement.  The first approach is generally misguided, IMO.
>
> It is simply not the case that "all packages should be using
> font-lock-* faces as far as possible."  That is bad advice, IMO.
> Package designers should use their heads, keeping the package users
> foremost in mind.
>
> I also wonder about this part:
>
>> > Then the themes can all set the same set of faces much more
>> > easily.
>
> Why should I care how easy it is for "themes to set" the same
> set of faces?  What I care about is how easy it is for users
> to customize a set of faces.  And for users of themes to control
> them.
>
> Now if it is the case that custom themes are "BAD", in that there
> is no easy way to customize a set of faces across multiple
> themes, then that would be something missing in the design of
> custom themes.  That would not surprise me, but I'm no expert on
> custom themes.

Just looking at the discrepancy between manoj-dark and the other
themes should make the problem clear.

-- 
Dan Espen

RE: custom-themes BAD?

[Drew Adams]

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

Re: custom-themes BAD?

[Dan Espen]

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

Re: custom-themes BAD?

[Rainer M Krug]

[-- 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 --]

Re: custom-themes BAD?

[Dan Espen]

Rainer M Krug <Rainer@krugs.de> writes:

> Dan Espen <despen@verizon.net> writes:
>> 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.

It should be a simple matter for all themes to run a hook that removes
the previous theme.  Then have each theme define it's own hook function.
But removing a face won't revert to the prior face, so each theme would
have to query the current setting, then save it in the hook function
for removal.

I think it would be far easier to just have a set of about 20 or 30 faces
that a theme is expected to set so the next theme can override those
same 20 to 30 faces.  Note, I'm not claiming 20 to 30 faces would be
sufficient, but manoj-dark is almost 800 lines long.  Certainly no one
needs or wants 800 different faces.

-- 
Dan Espen

Re: custom-themes BAD?

[Rainer M Krug]

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

Dan Espen <despen@verizon.net> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Dan Espen <despen@verizon.net> writes:
>>> 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.
>
> It should be a simple matter for all themes to run a hook that removes
> the previous theme.  Then have each theme define it's own hook function.
> But removing a face won't revert to the prior face, so each theme would
> have to query the current setting, then save it in the hook function
> for removal.

Exactly - should not be to difficult to implement.

>
> I think it would be far easier to just have a set of about 20 or 30 faces
> that a theme is expected to set so the next theme can override those
> same 20 to 30 faces.  Note, I'm not claiming 20 to 30 faces would be
> sufficient, but manoj-dark is almost 800 lines long.  Certainly no one
> needs or wants 800 different faces.

Well - 2 faces would again be easier...
Don't get me wrong - 800 is a lot. But I am using manoj-dark at the moment
and I really like it. The question should not be: how many do we need?
But how can we manage these effectively.
And removal hooks would be one very important step in the right
direction. And the effort would then be with the theme author as they
have to write the removal / restore functions, and not with anybody
else.

Cheers,

Rainer

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

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

Re: custom-themes BAD?

[W. Greenhouse]

Rainer M Krug <Rainer-vfylz/Ys1k4@public.gmane.org> writes:

> Dan Espen <despen-H+0wwilmMs3R7s880joybQ@public.gmane.org> writes:

[...]

>> It should be a simple matter for all themes to run a hook that removes
>> the previous theme.  Then have each theme define it's own hook function.
>> But removing a face won't revert to the prior face, so each theme would
>> have to query the current setting, then save it in the hook function
>> for removal.
>
> Exactly - should not be to difficult to implement.

The by-default-cumulative behavior of themes is confusing to newbies,
but there is already `disable-theme'.  `load-theme' does not normally
call `disable-theme' on the rest of `custom-enable-themes' prior to
loading a new one, but you could advice it to do so.  See also M-x
customize-themes, which already is hooked up to enable one theme at a
time, removing others.

RE: custom-themes BAD?

[Drew Adams]

> The by-default-cumulative behavior of themes is confusing to newbies,
> but there is already `disable-theme'.  `load-theme' does not normally
> call `disable-theme' on the rest of `custom-enable-themes' prior to
> loading a new one, but you could advice it to do so.  See also M-x
> customize-themes, which already is hooked up to enable one theme at a
> time, removing others.

As W. Greenhouse should know, `disable-theme', even applied to
all custom themes that have ever been enabled in the session,
does not restore customizations that were present before enabling
any theme.  I.e., it does not restore non-theme settings that
enabling a theme wiped out.

Put differently, you cannot "undo" the application of custom
themes, to return to the state before applying a theme.  You
can only disable custom themes relative to each other - in
general, you cannot fall back to a non-theme state.  You can
swap one custom theme for another, but any non-theme state
before applying a custom theme is lost.

For others, unfamiliar with the bug report:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687.
(The bug title was inappropriately renamed - the bug is not
particularly about variables.)

IMO, this represents a major deficiency of custom themes
compared to color themes (library `color-theme.el',
http://www.nongnu.org/color-theme/).

With color themes you can restore a pre-theme state.  It is
simple to take a snapshot of the current Emacs state as a
new (pseudo) theme ([Reset]), and then return to it after
enabling other themes.  What is missing for custom themes, IMO,
is the ability to take a snapshot of the current Emacs
appearance as a theme.

This, plus performance problems, mean that custom themes
cannot yet replace color themes, in general.  That's too bad;
it would be great if they could.  Custom themes do both more
and less than color themes.

(See bug #15740 about performance:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15740.)