customization theme users/use-cases/info

customization theme users/use-cases/info

[Dave Abrahams]

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,

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

Re: customization theme users/use-cases/info

[joakim]

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

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

-- 
Joakim Verona

Policy for backwards-incompatible changes? (was: customization theme users/use-cases/info)

[Dave Abrahams]

on Fri Oct 21 2011, joakim-AT-verona.se wrote:

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

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

Re: Policy for backwards-incompatible changes?

[Chong Yidong]

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

Re: Policy for backwards-incompatible changes?

[Dave Abrahams]

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

Re: Policy for backwards-incompatible changes?

[Chong Yidong]

Dave Abrahams <dave@boostpro.com> writes:

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

Yes, if you are willing to write a patch for that, I can certainly take
a look at it.  OTOH it should go into 24.2 rather than 24.1, but that
depends on how invasive the change turns out to be.

Re: customization theme users/use-cases/info

[Chong Yidong]

Dave Abrahams <dave@boostpro.com> writes:

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

FWIW, this is on my TODO list.

Re: customization theme users/use-cases/info

[Dave Abrahams]

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

> Dave Abrahams <dave@boostpro.com> writes:
>
>> 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.
>
> FWIW, this is on my TODO list.

Which of these, in particular?  Or all of them?

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

Re: customization theme users/use-cases/info

[Chong Yidong]

Dave Abrahams <dave@boostpro.com> writes:

> on Mon Oct 24 2011, Chong Yidong <cyd-AT-gnu.org> wrote:
>
>> Dave Abrahams <dave@boostpro.com> writes:
>>
>>> 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.
>>
>> FWIW, this is on my TODO list.
>
> Which of these, in particular?  Or all of them?

Documenting themes in the Emacs manual and Lisp manual.