Re: Policy for backwards-incompatible changes?

[Dave Abrahams <dave@boostpro.com>]

on Mon Oct 24 2011, Chong Yidong <cyd-AT-gnu.org> wrote:

> Dave Abrahams <dave@boostpro.com> 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.  

So it would be automatically inserted at the front of the list if it
wasn't already there, as a way to preserve backward compatibility.  I
like it!

However, we would still be breaking backward compatibility in that
enabling a theme with a setting already in the "user" theme would
now override that setting.  If that doesn't bother anyone, I'm happy
with it.

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

So it sounds like you would be open to accepting a patch that would
implement this?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com