Re: Policy for backwards-incompatible changes?

[Chong Yidong]

Dave Abrahams <address@hidden> writes:

> This, and the fact that I've received no other answers, support my
> suspicion that the design of themes may not be working well for the
> user community.  As far as I can tell, the only thing required to make
> themes work as you and I would want them to would be to give the
> "user" (i.e. default) theme lowest priority rather than highest.
>
> But this is a fairly radical change to make silently.  What would need
> to happen before something like that could be done?

One would have to fix the Customize interface, which currently assumes
that the user theme takes precedence over themed variables (e.g. it
marks themed but not customized variables as THEMED).

If that is fixed, I think the way to handle the theme and Customize
interaction is to add the `user' theme to the custom-enabled-themes
variable, so that it is treated on a similar footing to themes---the
user can explicitly specify their relative priorities.  (The
`custom-enabled-themes' variable itself would have to be treated
specially, of course, but that's also the case currently; you can set it
from a theme.)

The commands like `load-theme', if called interactively, could prompt
for whether or not to override the `user' theme.