Re: color-theme.el

[Richard Stallman]

    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.

This may not be a very large job, but the first part is not
trivial--do you want to do it?

As for the feature of using multiple themes, of being able to add and
remove themes from the list and have the right thing happen, I think I
see an easy way to add that.  We just have to make sure that each
theme function saves the old values of the variables that it sets, so
that it can "turn itself off" later on.

Then, when the user edits the list of currently enabled themes, here's
what you do.  You turn off all the themes in the list, in reverse
order.  You change the list.  Then you turn on the themes that are now
in the list.

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

That would work at startup.  To make it work right for editing the
list later would take a little more.  These theme functions could
carefully avoid setting variables that are marked as customized.

This probably means that instead of using setq directly, they should
use a macro `theme-setq' to set each variable.  The macro would take care of
recording the old value, not setting variables that are customized,
etc.

Would this give equivalent benefits to cus-theme.el?

    Your scheme won't integrate cleanly with customize (the option will be
    marked "rogue", i.e. "option is changed outside customize"), which is
    my major emotional problem with it.

Would it be difficult to create a new status value, "set by a theme"?
theme-setq could mark the variable with this status.


Meanwhile, would anyone be willing to step forward to integrate
cus-theme.el into Emacs?