Color themes

Color themes

[Chong Yidong]

Many of you are probably aware of a package called color-theme.el,
currently maintained by Xavier Maillard.  This package provides a
relatively easy way to choose from a list of pre-selected "color
themes" for font-lock keywords.  I think this kind of functionality
would be good.  For new users who dislike the default color palette,
there's currently no easy way to choose a different palette.

Ideally, there should be a submenu in the menu-bar, under Options, to
select a color theme (or whatever we end up calling it).

However, I'm ambivalent about how color-theme.el is written.  From a
perfunctory inspection of the code, it looks like it sets up some
infrastructure for defining color-themes that I'm not sure is a good
fit for Emacs.  In particular, it might be cleaner to define color
themes using Custom Themes, which were implemented in Emacs 22 and
meshes with the Customize facility.  I might be wrong, however, so
comments are welcome.

At this early stage, I haven't looked into the copyright assignment
issue for color-theme.el.  Assuming papers aren't a problem, I'm
thinking we could absorb part of the color-theme project, i.e. the
color settings that they've collected, and rewrite the theme-choosing
infrastructure based on Custom Themes.

Any thoughts?

Re: Color themes

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Many of you are probably aware of a package called color-theme.el,
  > currently maintained by Xavier Maillard.  This package provides a
  > relatively easy way to choose from a list of pre-selected "color
  > themes" for font-lock keywords.  I think this kind of functionality
  > would be good.  For new users who dislike the default color palette,
  > there's currently no easy way to choose a different palette.
  > 
  > Ideally, there should be a submenu in the menu-bar, under Options, to
  > select a color theme (or whatever we end up calling it).
  > 
  > However, I'm ambivalent about how color-theme.el is written.  From a
  > perfunctory inspection of the code, it looks like it sets up some
  > infrastructure for defining color-themes that I'm not sure is a good
  > fit for Emacs.  In particular, it might be cleaner to define color
  > themes using Custom Themes, which were implemented in Emacs 22 and
  > meshes with the Customize facility.  I might be wrong, however, so
  > comments are welcome.
  > 
  > At this early stage, I haven't looked into the copyright assignment
  > issue for color-theme.el.  Assuming papers aren't a problem, I'm
  > thinking we could absorb part of the color-theme project, i.e. the
  > color settings that they've collected, and rewrite the theme-choosing
  > infrastructure based on Custom Themes.
  > 
  > Any thoughts?

One main problem with color-theme.el is that it smashes the face
definitions.  
With multi-tty and the default face definitions you can do things like:

emacs -f server-start

rxvt -fg white -bg black  
and in rxvt do emacsclient -t

then start another rxvt with a different fg/bg:
rxvt -fg black -bg white 
and in there do emacsclient -t

[rxvt not xterm with emacs knows how to find out the default fg/bg color].

All the emacs/eamcsclient frames in the example above will get the
correct face definitions for the type of display they run on. 
That does not work anymore if one uses color-theme.el (and quite likely
Custom Themes).

Just my 2 cents.

Re: Color themes

[Eric Lilja]

Chong Yidong wrote:
> Many of you are probably aware of a package called color-theme.el,
> currently maintained by Xavier Maillard.  This package provides a
> relatively easy way to choose from a list of pre-selected "color
> themes" for font-lock keywords.  I think this kind of functionality
> would be good.  For new users who dislike the default color palette,
> there's currently no easy way to choose a different palette.
> 
> Ideally, there should be a submenu in the menu-bar, under Options, to
> select a color theme (or whatever we end up calling it).
> 
> However, I'm ambivalent about how color-theme.el is written.  From a
> perfunctory inspection of the code, it looks like it sets up some
> infrastructure for defining color-themes that I'm not sure is a good
> fit for Emacs.  In particular, it might be cleaner to define color
> themes using Custom Themes, which were implemented in Emacs 22 and
> meshes with the Customize facility.  I might be wrong, however, so
> comments are welcome.
> 
> At this early stage, I haven't looked into the copyright assignment
> issue for color-theme.el.  Assuming papers aren't a problem, I'm
> thinking we could absorb part of the color-theme project, i.e. the
> color settings that they've collected, and rewrite the theme-choosing
> infrastructure based on Custom Themes.
> 
> Any thoughts?
> 
> 
> 

I'm, sad to say, not a developer, but I'd love to see color theme as an 
official emacs package! Hopefully it can be made to play nice with all 
other emacs features. Sorry for the noise but I felt I needed to say that.

- Eric

Re: Color themes

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Fri, 29 Feb 2008 15:49:00 -0800
> Cc: emacs-devel@gnu.org
> 
> With multi-tty and the default face definitions you can do things like:
> 
> emacs -f server-start
> 
> rxvt -fg white -bg black  
> and in rxvt do emacsclient -t
> 
> then start another rxvt with a different fg/bg:
> rxvt -fg black -bg white 
> and in there do emacsclient -t
> 
> [rxvt not xterm with emacs knows how to find out the default fg/bg color].
> 
> All the emacs/eamcsclient frames in the example above will get the
> correct face definitions for the type of display they run on. 
> That does not work anymore if one uses color-theme.el (and quite likely
> Custom Themes).

OTOH, perhaps whoever uses color themes wants all their frames to use
the same face definitions?

Re: Color themes

[Xavier Maillard]

Hi,

   Any thoughts?

As you have mentionned it, I am the current maintainer of this
package. Currently, there is not much developments done *but*
there is many things to do. I do not considerate the package
status to be mature enough.

Yes it works, yes it is stable but there are many things planned
before it could eventually enter GNU Emacs TRUNK.

If you have questions regarding legal status or anything related
to this package (enhancements to do, etc.) I would be happy to
discuss them.

Current development is stalled but I received many requests by
mail (new themes, bug reports, etc.) and I am planning to
resurrect this project as soon as I get enough time to do it
seriously. Then will come the time to release 7.0 version that
would probably fit better and match with criterias to be part of
the GNU Emacs mainline development.

Regards,

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: Color themes

[joakim]

Juri Linkov <juri@jurta.org> writes:

>>> The right solution, of course, is to add a color theming support to Emacs
>>> with an easy way to switch themes and to create the `emacs-23.1' color theme.
>>
>> That would indeed be splendid.
>>
>> Can't we start merging the existing color-theme package, and iron out
>> whatever wrinkles it has?
>
> Do you know how this color-theme package is related to already existing
> custom-theme package `cus-theme.el' in Emacs?

No, I have no idea.

I only use color-theme to get my favorite color theme,
color-theme-dark-laptop. The main benefit of color-theme is all the nice
themes you can easily try.

If theres already a theme function in Emacs, color-theme:s themes could
be adapted to use that facility instead.

-- 
Joakim Verona

Re: Color themes

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

> Do you know how this color-theme package is related to already existing
> custom-theme package `cus-theme.el' in Emacs?

It's not at all related.

I do think it's much easier to use our existing custom theme code to
implement color themes, instead of the (from my last inspection, rather
complicated) machinery in color-theme.el.  Especially if we only want to
provide a small simple selection of color themes, instead of the
multitude provided by color-theme.el.

Re: Color themes

[Leo]

On 2009-08-09 04:04 +0100, Chong Yidong wrote:
> Juri Linkov <juri@jurta.org> writes:
>
>> Do you know how this color-theme package is related to already existing
>> custom-theme package `cus-theme.el' in Emacs?
>
> It's not at all related.
>
> I do think it's much easier to use our existing custom theme code to
> implement color themes, instead of the (from my last inspection, rather
> complicated) machinery in color-theme.el.  Especially if we only want to
> provide a small simple selection of color themes, instead of the
> multitude provided by color-theme.el.

I also don't like color-theme, in particular, how the themes are created
by re-defining all faces. A comprehensive theme could easily run up to a
few thousand lines and it still does not offer 100% coverage, let alone
consistency.

Perhaps a color theme should be defined to be something like a palette
and when a palette is selected defface is forced to only use colors in
it. For example the tango project uses 27 colors.
http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines.

On a side note, Textmate seems to offer the best color themes. See the
following url for many beautiful themes submitted by its users.

http://wiki.macromates.com/Themes/UserSubmittedThemes

Leo

-- 
Leo's Emacs uptime: 5 days, 3 hours, 44 minutes, 7 seconds

Re: Color themes

[Chong Yidong]

Leo <sdl.web@gmail.com> writes:

> I also don't like color-theme, in particular, how the themes are created
> by re-defining all faces. A comprehensive theme could easily run up to a
> few thousand lines and it still does not offer 100% coverage, let alone
> consistency.
>
> Perhaps a color theme should be defined to be something like a palette
> and when a palette is selected defface is forced to only use colors in
> it.

This is exactly the kind of problem that Custom themes is intended to
solve.  The code for *creating* custom themes is still a little buggy,
but the code for *using* it should work, and we ought to be able to make
use of it to set color themes.

Here's an example.  Create a file called forest-theme.el, with the
contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
RET forest RET, or customize custom-enabled-themes and add `forest' to
the list.

So if we want to use this mechanism to implement color themes, it's just
a matter of adding some *-theme.el files to the load path, and adding a
command to add that theme to custom-enabled-themes.

As you can see, (i) your existing face customizations, if any, will
override the color theme, as they should, and (ii) it doesn't take a lot
of code to define a color theme using this method.


======= start forest-theme.el ============

(deftheme forest
  "Created 2009-08-09.")

(custom-theme-set-faces
 'forest
 '(default ((t (:foreground "wheat" :background "black"))))
 '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
 '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
 '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
 '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
 '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
 '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
 '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
 '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
 '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
 '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
 '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))

(provide-theme 'forest)

======= end forest-theme.el ============

Re: Color themes

[CHENG Gao]

*On Sun, 09 Aug 2009 12:18:01 -0400
* Also sprach Chong Yidong <cyd@stupidchicken.com>:

> Leo <sdl.web@gmail.com> writes:
>
>> I also don't like color-theme, in particular, how the themes are created
>> by re-defining all faces. A comprehensive theme could easily run up to a
>> few thousand lines and it still does not offer 100% coverage, let alone
>> consistency.
>>
>> Perhaps a color theme should be defined to be something like a palette
>> and when a palette is selected defface is forced to only use colors in
>> it.
>
> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.
>
>
> ======= start forest-theme.el ============
>
> (deftheme forest
>   "Created 2009-08-09.")
>
> (custom-theme-set-faces
>  'forest
>  '(default ((t (:foreground "wheat" :background "black"))))
>  '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
>  '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
>  '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
>  '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
>  '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
>  '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
>  '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
>  '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
>  '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
>  '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
>  '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))
>
> (provide-theme 'forest)
>
> ======= end forest-theme.el ============

I must say I like this way very much. I just tested your theme, and it
works, though not super gorgeous :-P


-- 
Volo, non valeo

Re: Color themes

[Lennart Borgman]

On Sun, Aug 9, 2009 at 6:18 PM, Chong Yidong<cyd@stupidchicken.com> wrote:

> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.


Thanks for the example. This looks very good (I don't mean the colors ... ;-).

I was kind of reinventing that. Sigh.

Could we please get this working? Making it easy to use etc. Good
prompting for themes so it is easy to switch, easy to reset ... Maybe
some kind of "list-themes" with the doc strings...

Then we can also make those Mac-themes, w32-themes,
emacs-as-it-always-was-theme ...

Re: Color themes

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> Leo <sdl.web@gmail.com> writes:
>
>> I also don't like color-theme, in particular, how the themes are created
>> by re-defining all faces. A comprehensive theme could easily run up to a
>> few thousand lines and it still does not offer 100% coverage, let alone
>> consistency.
>>
>> Perhaps a color theme should be defined to be something like a palette
>> and when a palette is selected defface is forced to only use colors in
>> it.
>
> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.

While I havent tested this, it seems great!

Can we somehow create a machine translator from color-theme.el to
custom-theme? 

>
>
> ======= start forest-theme.el ============
>
> (deftheme forest
>   "Created 2009-08-09.")
>
> (custom-theme-set-faces
>  'forest
>  '(default ((t (:foreground "wheat" :background "black"))))
>  '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
>  '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
>  '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
>  '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
>  '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
>  '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
>  '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
>  '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
>  '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
>  '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
>  '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))
>
> (provide-theme 'forest)
>
> ======= end forest-theme.el ============
>
-- 
Joakim Verona

Re: Color themes

[Leo]

2009/8/9 Chong Yidong <cyd@stupidchicken.com>:
> Leo <sdl.web@gmail.com> writes:
>
>> I also don't like color-theme, in particular, how the themes are created
>> by re-defining all faces. A comprehensive theme could easily run up to a
>> few thousand lines and it still does not offer 100% coverage, let alone
>> consistency.
>>
>> Perhaps a color theme should be defined to be something like a palette
>> and when a palette is selected defface is forced to only use colors in
>> it.
>
> This is exactly the kind of problem that Custom themes is intended to
> solve.  The code for *creating* custom themes is still a little buggy,
> but the code for *using* it should work, and we ought to be able to make
> use of it to set color themes.
>
> Here's an example.  Create a file called forest-theme.el, with the
> contents shown below, and put it in .emacs.d.  Then do M-x enable-theme
> RET forest RET, or customize custom-enabled-themes and add `forest' to
> the list.
>
> So if we want to use this mechanism to implement color themes, it's just
> a matter of adding some *-theme.el files to the load path, and adding a
> command to add that theme to custom-enabled-themes.
>
> As you can see, (i) your existing face customizations, if any, will
> override the color theme, as they should, and (ii) it doesn't take a lot
> of code to define a color theme using this method.
>
>
> ======= start forest-theme.el ============
>
> (deftheme forest
>  "Created 2009-08-09.")
>
> (custom-theme-set-faces
>  'forest
>  '(default ((t (:foreground "wheat" :background "black"))))
>  '(font-lock-comment-face ((((class color) (min-colors 88)) (:foreground "medium sea green"))))
>  '(font-lock-constant-face ((((class color) (min-colors 88)) (:foreground "turquoise"))))
>  '(font-lock-function-name-face ((((class color) (min-colors 88)) (:foreground "pale green"))))
>  '(font-lock-keyword-face ((((class color) (min-colors 88)) (:foreground "white"))))
>  '(font-lock-string-face ((((class color) (min-colors 88)) (:foreground "dark khaki"))))
>  '(font-lock-type-face ((((class color) (min-colors 88)) (:foreground "medium aquamarine"))))
>  '(font-lock-variable-name-face ((((class color) (min-colors 88)) (:foreground "yellow green"))))
>  '(font-lock-warning-face ((((class color) (min-colors 88)) (:foreground "salmon1"))))
>  '(font-lock-builtin-face ((((class color) (min-colors 88)) (:foreground "LightSteelBlue"))))
>  '(region ((((class color) (min-colors 88)) (:foreground "white" :background "dark green"))))
>  '(highlight ((((class color) (min-colors 88)) (:foreground "white" :background "dark green")))))
>
> (provide-theme 'forest)
>
> ======= end forest-theme.el ============

Thank you Chong.

I failed to see how consistency can be reached through this.

For example, if a package define faces that do not inherit from the
faces in the theme, then enabling the theme won't affect them, right?

I am thinking about if each buffer is an icon, how to make sure they
look like, for example, tango by using the 28 colors in its style
guide only.

Leo

Re: Color themes

[Juri Linkov]

> I am thinking about if each buffer is an icon, how to make sure they
> look like, for example, tango by using the 28 colors in its style
> guide only.

Color themes and palettes are different things but both are useful.
A color theme redefines every face individually whereas a palette
reduces them to a list of predefined colors.

Actually, Emacs already has palette support on text-only terminals
with a small number of colors with the help of the function
`tty-color-approximate' that finds the closest color among the
known colors.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Color themes

[Leo]

On 2009-08-11 00:48 +0100, Juri Linkov wrote:
>> I am thinking about if each buffer is an icon, how to make sure they
>> look like, for example, tango by using the 28 colors in its style
>> guide only.
>
> Color themes and palettes are different things but both are useful.
> A color theme redefines every face individually whereas a palette
> reduces them to a list of predefined colors.
>
> Actually, Emacs already has palette support on text-only terminals
> with a small number of colors with the help of the function
> `tty-color-approximate' that finds the closest color among the
> known colors.

Well if you consider that a palette, it is one forced by the limitation
of the terminal. So you can't carefully pick good colours to form a
palette for text editing.

-- 
Leo's Emacs uptime: 7 days, 1 hour, 1 minute, 39 seconds

Re: Color themes

[Chong Yidong]

Leo <sdl.web@googlemail.com> writes:

> I failed to see how consistency can be reached through this.
>
> For example, if a package define faces that do not inherit from the
> faces in the theme, then enabling the theme won't affect them, right?

Most faces inherit from the basic faces (default, bold, italic, region,
etc.) plus the font-lock faces.  Or at least they should.

Re: Color themes

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > Leo <sdl.web@googlemail.com> writes:
  > 
  > > I failed to see how consistency can be reached through this.
  > >
  > > For example, if a package define faces that do not inherit from the
  > > faces in the theme, then enabling the theme won't affect them, right?
  > 
  > Most faces inherit from the basic faces (default, bold, italic, region,
  > etc.) plus the font-lock faces.  

Unfortunately that is not always true. :-(
emacs -Q 
M-x list-faces-display 
will show a few that do not: buffer-menu-buffer, mode-line-buffer-id, 
mode-line-emphasis, and that is just looking for things that look bold.

  > Or at least they should.

Agreed.   

RE: Color themes

[Drew Adams]

>   > Most faces inherit from the basic faces (default, bold, 
>   > italic, region, etc.) plus the font-lock faces.  
> 
> Unfortunately that is not always true. :-(
>
>   > Or at least they should.
> 
> Agreed.   

Why?

(No reasons given.)

RE: Color themes

[Drew Adams]

> Most faces inherit from the basic faces (default, bold, 
> italic, region, etc.) plus the font-lock faces.
> Or at least they should.

Huh? Where does it say that? Since when?

What possible reason could there be for saying that it's OK to inherit from
basic face `escape-glyph' (for example) but not OK to define your own face
without inheriting from any "basic face" or a font-lock face. What's so special
about the "basic faces" and font-lock faces? When you defined face
`escape-glyph', what made you decide it was a "basic face"?

I find nothing anywhere in the Emacs or Elisp manual that suggests that
inheriting is good and not inheriting is bad, let alone that one should inherit
(ultimately) from one of the "basic faces" or a font-lock face.

And what makes a face a "basic face", anyway? 

I see nothing in the doc that even defines any notion of "basic face". There is
no mention of it in the Emacs manual. The only use of that term in the Elisp
manual is in the example defface for face `region' (only in its doc string and
:group).

There is a customize group named `basic-faces' (with 35 faces in it), but we all
know how little meaning to ascribe to customize groups or their names.

And if someone uses :group 'basic-faces in a defface, then presumably that
creates a new basic face? Belonging to :group `basic-faces' certainly can't be
the real meaning of the concept "basic face".

So do we now have a new guideline - "Thou shalt inherit from a basic face" -
that has no meaning? Next thing you know, someone will add that commandment to
the doc, having picked it up from your post. Another rule for the Emacs
Catechism, with no reasons given...

Re: Color themes

[Leo]

Hi Yidong,

On 2009-08-11 04:58 +0100, Chong Yidong wrote:
>> For example, if a package define faces that do not inherit from the
>> faces in the theme, then enabling the theme won't affect them, right?
>
> Most faces inherit from the basic faces (default, bold, italic, region,
> etc.) plus the font-lock faces.  Or at least they should.

I see inheritance as a convenient tool for defining new faces, but not
an effective tool for enforce consistency. Even if all faces inherit
from more basic ones, they can still choose to use different colours and
in reality this is what happens.

-- 
Leo's Emacs uptime: 7 days, 8 hours, 53 minutes, 56 seconds

Re: Color themes

[ferkiwi]

On Tue, Aug 11, 2009 at 10:59 AM, Leo<sdl.web@gmail.com> wrote:
> I see inheritance as a convenient tool for defining new faces, but not
> an effective tool for enforce consistency. Even if all faces inherit
> from more basic ones, they can still choose to use different colours and
> in reality this is what happens.

Personally, when I have to choose a color theme I prefer the theme
that has the most different and distinguishable colors. There are some
color-themes that have the very same color for many different faces
and I think that's defeating the point of selective highlighting. I
like when I'm able to know what's the role of a word by looking at its
unique color. I like to be able to give specific colors to
flymake-errline or hl-line faces, they would be kind of unusable if
they had the same colors from a reduced basic set (I can't use
hl-line-mode with emacs in a terminal because of this, it's not
comfortable for me to have such a bright line due to the reduced set
of terminal colors).

So, while I agree that inheriting colors is good for making it easy to
develop new themes, I think that allowing the themes to change
selectively the color of "non-standard" faces is also good, imho. And
I think this two things are not mutually excluding.

--
Fernando