Re: color-theme.el

[Per Abrahamsen <abraham@dina.kvl.dk>]

Alex Schroeder <alex@emacswiki.org> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
> First, let us look at the kind of effort involved in using
> cus-theme.el.  To create a theme involves about as much work as
> writing a setq statement for all the variables, and giving this
> collection of settings a name.  So for an author, there is no benefit
> compared to writing a defun.  The defun has a name and can set tons of
> variables.  The benefit for users is that undoing the theme is
> straightforward.

Jan Vroonhofs code is only the first (Lisp) step, the second step
would be to add theme commands to the customize UI, like "add setting
to theme", and "save theme".

This would allow users with no knowledge of Lisp to create and share
customizations, and, in my opinion, give them a first taste of the
free software culture of sharing.

They already do this, but they share entire "customize-set-variables"
sections, which we know doesn't work well.

> If this is the only benefit,

It isn't.  Large packages like Gnus can offer "build-in" themes for
e.g. slow and fast connections, and fancy and boring display (which in
Gnus involves much more than just faces).

Emacs itself could come with some themes, such as an "Emacs 20" theme
for people who dislike the UI changes in Emacs 21.

> however, then perhaps we are better off with another solution
> altogether: Let us create a new list of functions to call at
> startup.  Let us call it `startup-functions'.  Let us make this
> customizable.  Now site authors can install a suitable default, and
> users can still customize it to their liking.  The customizations
> will be saved to their .emacs file.  Problem solved!  And the
> solution was easy to understand.

The problem is that any individual option set by "setq" from a funtion
in such a list will overwrite the users individual customization of
that item.  With Jans themes it is the other way around, the explicit
individual settings will overwrite the the settings.

This benefit come both from package themes, other users themes, and
site themes.  They could all be done with functions and setq, but Jans
themes makes it possible to prioritize them when they conflict, and
overwrite individual options.

> "As far as I am concerned, these last years have shown that there is
> just no need for that."

I don't think you can scale the experience gained from the existence
of an unbundled package, to themes being integrated in Emacs.
Hopefully, the later will mean many more themes will be available,
with increasing need for conflict resolution and overwriting
individual choises.