[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Policy for backwards-incompatible changes?

From: Dave Abrahams
Subject: Re: Policy for backwards-incompatible changes?
Date: Mon, 31 Oct 2011 11:13:21 -0800
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin)

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]