[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Policy for backwards-incompatible changes? (was: customization theme use
Policy for backwards-incompatible changes? (was: customization theme users/use-cases/info)
Sun, 23 Oct 2011 13:09:31 -0400
Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin)
on Fri Oct 21 2011, joakim-AT-verona.se wrote:
> Dave Abrahams <address@hidden> writes:
>> I've been trying to use the themes feature that's been in Emacs since
>> v23.x, and I am finding it a little bit awkward... most of what's in
>> Emacs is oriented around using the regular customization interface,
>> which stomps on anything set up by a theme. There isn't much
>> information in the Emacs manual about how one might use themes, there's
>> no information on EmacsWiki, and the facilities go un-mentioned in the
>> Elisp manual. I might expect to find information there about the theme
>> data structure, for example. Especially because of the silence of
>> EmacsWiki (I think I made the one page that mentions themes there---no,
>> color-theme is something different) it makes me wonder how the feature
>> was designed, who's actually using it, and whether they're being
>> well-served by it.
>> Any information appreciated,
> I'm using themes in my zen-mode.el package. I use it to create a
> stackable set of features. Maybe it's easier with an example:
> 1: A
> 2: A B
> 3: A B C
> so; A B C are features. 0 1 2 3 are levels that you can switch between.
> Customize makes this feature a bit problematic, as you have observed. It
> happens frequently that a variable I want the theme to own winds up in
> the default customize level instead. Then my entire stack fails, since
> it means feature C winds up in level 0. I haven't delved much further. I
> reported a bug at least.
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?
Obviously, more complicated schemes that preserve backward-compatible
semantics are possible, but personally I wouldn't want to add the
complexity without hearing from at least one person who values the
current semantics before considering adding complexity.