RE: Why is custom--inhibit-theme-enable not t by default?

[Drew Adams <drew.adams@oracle.com>]

> >   > > Doesn't the command disable-theme undo the application of a
> >   > > custom theme?
> >
> >   > No.  Summary: There is no function that takes a snapshot
> >   > of the Emacs state (even, e.g., as a custom theme) before
> >   > applying any custom theme - which snapshot can then be used
> >   > to restore that pre-theme state.
> >
> > Perhaps we should redesign the way themes work
> > so that a theme is represented by data that says what it does,
> > and we could turn it on and off.
> 
> I don't think we need to redesign them, really: we simply need to say
> that loading the file won't enable the theme any more.  Also loading
> such a file should not have any "visible" side effect (same rule as for
> Elisp packages).
> 
> If a theme needs to run arbitrary code, it simply needs to define its
> own global minor mode `my-foo-mode` and then within its custom settings,
> it needs to set `my-foo-mode` to t.
> 
> Themes which follow these rules should work just fine in current
> Emacsen, so we can simply introduce this new rule, just like we did
> (a long time ago) when we decided that loading an Elisp file
> should be harmless.
> 
> AFAICT the themes bundled with Emacs already obey the rule.

AFAICS, you addressed the question of whether loading a theme
should activate it, but you did not address the point to which
you replied: disabling a custom theme does not undo it.

Maybe that point should be in a separate thread; dunno.  But
it is a separate point from the point that loading should not
enable/activate.