Custom themes and simple variables

Custom themes and simple variables

[Ralf Angeli]

Hi,

in AUCTeX we've traditionally had files one could `require' to enable
various settings for different TeX systems and platforms.  For example
if the user loaded tex-mik.el the viewer Yap provided by MiKTeX would be
configured to be used for previewing DVI files instead of xdvi.

I thought something like this could be handled in a more flexible way
with custom themes.  However, it seems that variables defined with
`defvar' in contrast to `defcustom' are not supported because the
`defvar' statement "overwrites" the value set by an active theme.

Here is a simple test case:

$ echo "(deftheme foo \"foo theme\") (custom-theme-set-variables 'foo '(foo \"original\")) (provide-theme 'foo)" > foo-theme.el
$ emacs -Q --eval "(progn (add-to-list 'load-path \".\") (load-theme 'foo) (defvar foo \"changed\") (describe-variable 'foo))"

The first command defines a theme called "foo" and writes it to disk as
the file foo-theme.el.  The second command calls Emacs, tells it to load
the theme, define the variable `foo' (for which the theme also contains
a value) and show the value of it.  This will be "changed".  If you do
the same thing using `defcustom' instead of `defvar' the value will be
"original".

I assume the problem is due to a variable defined with `defvar' not
being supported by the Custom machinery, so this is likely not a bug.
Would there nevertheless be a possibility to handle such variables
cleanly with custom themes?

-- 
Ralf

Re: Custom themes and simple variables

[Chong Yidong]

Ralf Angeli <angeli@caeruleus.net> writes:

> $ echo "(deftheme foo \"foo theme\") (custom-theme-set-variables 'foo '(foo \"original\")) (provide-theme 'foo)" > foo-theme.el
> $ emacs -Q --eval "(progn (add-to-list 'load-path \".\") (load-theme 'foo) (defvar foo \"changed\") (describe-variable 'foo))"
>
> The first command defines a theme called "foo" and writes it to disk as
> the file foo-theme.el.  The second command calls Emacs, tells it to load
> the theme, define the variable `foo' (for which the theme also contains
> a value) and show the value of it.  This will be "changed".  If you do
> the same thing using `defcustom' instead of `defvar' the value will be
> "original".
>
> I assume the problem is due to a variable defined with `defvar' not
> being supported by the Custom machinery, so this is likely not a bug.
> Would there nevertheless be a possibility to handle such variables
> cleanly with custom themes?

Any variable that should be supported by Custom (including both
"vanilla" Custom and Custom themes) ought to be declared with defcustom.
Is there any reason the variables you are trying to work with are
`defvar'ed instead?

Re: Custom themes and simple variables

[Ralf Angeli]

* Chong Yidong (2009-10-23) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> I assume the problem is due to a variable defined with `defvar' not
>> being supported by the Custom machinery, so this is likely not a bug.
>> Would there nevertheless be a possibility to handle such variables
>> cleanly with custom themes?
>
> Any variable that should be supported by Custom (including both
> "vanilla" Custom and Custom themes) ought to be declared with defcustom.
> Is there any reason the variables you are trying to work with are
> `defvar'ed instead?

There is a built-in list of viewers the user can choose from.  And this
list is not supposed to be changed by the user.  Therefore it is
declared with `defvar'.  (The user can add or overwrite viewers in a
separate, customizable variable which is defined with `defcustom'.)

The idea now is that the list of predefined viewers only contains
viewers for the chosen platform.  Per default viewers available on
GNU/Linux would be offered but if a theme for MiKTeX on Windows were
enabled, only viewers available on Windows would be displayed.

-- 
Ralf

Re: Custom themes and simple variables

[Chong Yidong]

Ralf Angeli <angeli@caeruleus.net> writes:

> There is a built-in list of viewers the user can choose from.  And this
> list is not supposed to be changed by the user.  Therefore it is
> declared with `defvar'.  (The user can add or overwrite viewers in a
> separate, customizable variable which is defined with `defcustom'.)
>
> The idea now is that the list of predefined viewers only contains
> viewers for the chosen platform.  Per default viewers available on
> GNU/Linux would be offered but if a theme for MiKTeX on Windows were
> enabled, only viewers available on Windows would be displayed.

Why not automatically detect the system type in the initialization form
for either the defvar'ed list of built-in viewers, or the defcustom
default for the user viewer?  I.e., either

(defvar available-viewers (cond (eq system-type 'gnu/linux) ....))

or

(defcustom my-viewer (cond (eq system-type 'gnu/linux) ....))

depending on whichever makes more sense for the particular situation.

Re: Custom themes and simple variables

[Ralf Angeli]

* Chong Yidong (2009-10-23) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> The idea now is that the list of predefined viewers only contains
>> viewers for the chosen platform.  Per default viewers available on
>> GNU/Linux would be offered but if a theme for MiKTeX on Windows were
>> enabled, only viewers available on Windows would be displayed.
>
> Why not automatically detect the system type in the initialization form
> for either the defvar'ed list of built-in viewers, or the defcustom
> default for the user viewer?  I.e., either
>
> (defvar available-viewers (cond (eq system-type 'gnu/linux) ....))
>
> or
>
> (defcustom my-viewer (cond (eq system-type 'gnu/linux) ....))
>
> depending on whichever makes more sense for the particular situation.

The operating system is not the only condition influencing the list of
viewers (and at least one additional internal variable).  Another
important one is the TeX system in use.  And I could imagine that there
are even people with multiple TeX systems installed who'd like to be
able to switch between them.  Custom themes would make that quite
convenient.

Currently something like this is used in the files users can require to
activate platform-specific settings:

(unless (get 'TeX-kpathsea-path-delimiter 'saved-value)
  (setq TeX-kpathsea-path-delimiter nil))

It's working but it's a bit less convenient.

-- 
Ralf