Re: color-theme.el

[Alex Schroeder]

Per Abrahamsen <address@hidden> writes:

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

I had a very simple UI that would allow me to specify the variables
that are part of the theme, the name of theme, and a file name.  It
would then save the appropriate lisp code.  It was trivial.

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

I think we could write something like that without the need for
cus-theme.el.  A wizard using widget.el that lets you specify the
variables that are part of the theme, the name of theme, and a file
name.  It would then save the appropriate lisp code -- a bunch of setq
statements (in a defun, with appropriate call to `provide').

We would then modify the `startup-functions' idea I presented in an
earlier mail: Let it be called `startup-requires'.  Users could then
save the file with the generated setq statements in their load-path,
and customize `startup-requires' such that the appropriate theme is
loaded, and the variables are set, at startup time.

This would provide the user experience you describe, with very little
work required.

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

Sure -- but do we need the real theme code, with precedences,
selective uninstalling, etc?  Would a bunch of setq not do the job?
You think it would not, I think it would.  I don't think we can decide
that at the moment.  The only thing I know is that I have not seen any
requests for it, in the limited time I spend on the newsgroups these
days.

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

If we want that, let the customization of `startup-requires' be the
first thing acted upon when doing customization.  Then individual
settings will still overwrite stuff installed via startup-requires.

> I don't think you can scale the experience gained from the existence
> of an unbundled package, to themes being integrated in Emacs.

Well, if I cannot generalize it from the existing themes I maintain,
who is going to offer an opinion?  Nobody else is maintaining anything
like it.  We could compare it to Gnus group parameters, perhaps.
These are also settings saved outside of .emacs and custom.  Or the
.newsrc.el file.  But I find it difficult to draw conclusions from
it.  It seems to me that my basis for prediction is small, but
everybody else's basis is even smaller.

> Hopefully, the later will mean many more themes will be available,
> with increasing need for conflict resolution and overwriting
> individual choises.

I'm not sure how conflict resolution will actually improve.  I think
the user experience  will turn out to be something like this:  

A: Why does this and that not work?
B: What themes do you have installed?
A: X and Y.
B: Ah, these conflict, you must uninstall one of them.
A: Oh.

If so, then this user experience can be had using my simple idea I
offered at the top, using a widget to save setq in files, take
advantage of the require/provide conventions, introducing the new
option startup-requires, which means adding a bit of code to the place
where .emacs is read, and adding a bit of code to the place where
customizations are saved.  That seems to be far less than the entire
cus-theme.el stuff.  And I am saying these eventhough I ported Jan's
code from XEmacs to Emacs!

Alex.