Custom themes and precedence

Custom themes and precedence

[Dave Abrahams]

Hi all,

I thought I'd use themes to store groups of settings that should take
effect in specific circumstances; for example, on machine X, I have a
fonts not available elsewhere and I'd like to use those by default when
on machine X.  So I programmatically look for a theme based on the
machine name and if found, I enable it.

I customized default-frame-alist in the theme for machine X... which
worked fine until I customized default-frame-alist "non-themedly"
somewhere else.  That caused the new setting to go into the "user" theme
*which takes precedence over all others*.  That last bit isn't working
out so well for my use-case.  Should this usage be accomodated, is it
outside the intended applications of themes, or...?

TIA,

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

Re: Custom themes and precedence

[Chong Yidong]

Dave Abrahams <dave@boostpro.com> writes:

> I customized default-frame-alist in the theme for machine X... which
> worked fine until I customized default-frame-alist "non-themedly"
> somewhere else.  That caused the new setting to go into the "user" theme
> *which takes precedence over all others*.  That last bit isn't working
> out so well for my use-case.  Should this usage be accomodated, is it
> outside the intended applications of themes, or...?

Non-theme customization settings are intended to take precedence over
theme settings.  The idea is that if you load a theme that's not written
by you, it is easy to use Customize to override some of its settings.
I think I understand the problem you have, but I don't have any easy
solution.

Re: Custom themes and precedence

[Dave Abrahams]

on Sat Oct 01 2011, Chong Yidong <cyd-AT-stupidchicken.com> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> I customized default-frame-alist in the theme for machine X... which
>> worked fine until I customized default-frame-alist "non-themedly"
>> somewhere else.  That caused the new setting to go into the "user" theme
>> *which takes precedence over all others*.  That last bit isn't working
>> out so well for my use-case.  Should this usage be accomodated, is it
>> outside the intended applications of themes, or...?
>
> Non-theme customization settings are intended to take precedence over
> theme settings.  The idea is that if you load a theme that's not written
> by you, it is easy to use Customize to override some of its settings.

I guess the question is, what about themes that *are* written by me,
that I may want to switch on or off programmatically?

> I think I understand the problem you have, but I don't have any easy
> solution.

I know there's no easy solution within the code as-is.  I guess I'm
asking whether my desire for adjustable theme precedence ought to be
accomodated.

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

Re: Custom themes and precedence

[Stefan Monnier]

>>> I customized default-frame-alist in the theme for machine X... which
>>> worked fine until I customized default-frame-alist "non-themedly"
>>> somewhere else.  That caused the new setting to go into the "user" theme
>>> *which takes precedence over all others*.  That last bit isn't working
>>> out so well for my use-case.  Should this usage be accomodated, is it
>>> outside the intended applications of themes, or...?
>> Non-theme customization settings are intended to take precedence over
>> theme settings.  The idea is that if you load a theme that's not written
>> by you, it is easy to use Customize to override some of its settings.
> I guess the question is, what about themes that *are* written by me,
> that I may want to switch on or off programmatically?

One approach is to encourage such users to put all their customizations
into themes (i.e. avoid the "user" theme).


        Stefan

Re: Custom themes and precedence

[Dave Abrahams]

on Sat Oct 01 2011, Stefan Monnier <monnier-AT-iro.umontreal.ca> wrote:

>>>> I customized default-frame-alist in the theme for machine X... which
>
>>>> worked fine until I customized default-frame-alist "non-themedly"
>>>> somewhere else.  That caused the new setting to go into the "user" theme
>>>> *which takes precedence over all others*.  That last bit isn't working
>>>> out so well for my use-case.  Should this usage be accomodated, is it
>>>> outside the intended applications of themes, or...?
>>> Non-theme customization settings are intended to take precedence over
>>> theme settings.  The idea is that if you load a theme that's not written
>>> by you, it is easy to use Customize to override some of its settings.
>> I guess the question is, what about themes that *are* written by me,
>> that I may want to switch on or off programmatically?
>
> One approach is to encourage such users to put all their customizations
> into themes (i.e. avoid the "user" theme).

Heh.  Is that easier in Emacs24 than it is in 23?

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