customize-themes doesn't allow backquote or :inherit

customize-themes doesn't allow backquote or :inherit

[Yavuz]

Hello,
I have been trying out the customize-themes feature, and converting a
color-theme that I have to the new format. The problem I have is how to use
color variables instead of "#RRGGBB" type constants to ease design and
maintenance of themes. Initially I thought I could use something like:

(deftheme mytheme)
...
(defvar nice-color "#123456")
...
(custom-theme-set-faces 'mytheme
  `(default ((t (:foreground ,nice-color))))
  ...)
(provide-theme 'mytheme)

However, it seems that the load-theme function in custom.el has some code that
checks for the presence of 'quote and throws a 'Unsafe expression in theme
settings' error if I try to use ` instead of '.

Being an elisp newbie, my attempts to bypass is with various combinations of
eval, apply, and `' ended in failure.

Is there a way to use variables in custom-theme-set-faces? Or is that check
really need to be that strict? Maybe backquote would be acceptable as well?

Thanks in advance,
Yavuz

Re: customize-themes doesn't allow backquote or :inherit

[Chong Yidong]

Yavuz <justloop@gmail.com> writes:

> However, it seems that the load-theme function in custom.el has some
> code that checks for the presence of 'quote and throws a 'Unsafe
> expression in theme settings' error if I try to use ` instead of '.
>
> Being an elisp newbie, my attempts to bypass is with various
> combinations of eval, apply, and `' ended in failure.
>
> Is there a way to use variables in custom-theme-set-faces? Or is that
> check really need to be that strict? Maybe backquote would be
> acceptable as well?

This is worth discussing.

Currently, the code only evals custom-theme-set-variables/faces if its
arguments are quoted.  I was concerned about security implications; the
worry is that users may not be aware that loading a theme can execute
arbitrary code.

If people think this worry is unwarranted, I can change it to omit that
check.  Or, we can prompt the user if Emacs encounters a non-trivial
form in the custom theme file.

What's everyone's opinion?

Re: customize-themes doesn't allow backquote or :inherit

[Miles Bader]

If security is an issue, it seems reasonable to not blindly evaluate
... but it seems very confusing to "pretend" to evaluate.  Why not just
change the top-level wrapper to something that explicitly doesn't
evaluate its arguments?

-miles

-- 
Guilt, n. The condition of one who is known to have committed an indiscretion,
as distinguished from the state of him who has covered his tracks.

Re: customize-themes doesn't allow backquote or :inherit

[Stefan Monnier]

>> However, it seems that the load-theme function in custom.el has some
>> code that checks for the presence of 'quote and throws a 'Unsafe
>> expression in theme settings' error if I try to use ` instead of '.
>> 
>> Being an elisp newbie, my attempts to bypass is with various
>> combinations of eval, apply, and `' ended in failure.
>> 
>> Is there a way to use variables in custom-theme-set-faces? Or is that
>> check really need to be that strict? Maybe backquote would be
>> acceptable as well?

> This is worth discussing.

> Currently, the code only evals custom-theme-set-variables/faces if its
> arguments are quoted.  I was concerned about security implications; the
> worry is that users may not be aware that loading a theme can execute
> arbitrary code.

Why not use `unsafep'?


        Stefan

Re: customize-themes doesn't allow backquote or :inherit

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Why not use `unsafep'?

I forgot about that.  Thanks.

Re: customize-themes doesn't allow backquote or :inherit

[Yavuz]

Thinking a bit laterally, there are 2 alternate mechanisms that
could help (at the loss of some flexibility):

1. There are named colors, such as "royal blue" that one can use
instead of "#RRGGBB" format. If it were possible to user-define
more, that would be a solution.

2. There is the :inherit keyword that I couldn't get to work the
way I thought it would--allow the designer to define any face
attribute (and not just a color) once using a virtual face, and
then reuse it multiple times:

(custom-theme-set-faces 'mytheme
  '(highlighted-fg ((t (:foreground "#123456" :weight bold))))
  ...
  '(font-lock-error ((t (:inherit highlighted-fg) ...)


There is also a separate problem with saving a user-defined theme
for future sessions in any other directory than .emacs.d. I save
them in .emacs.d./themes, and set custom-theme-directory to it in
my customization file. Then I can interactively select it using
M-x customize-themes, and save it for future sessions (the name
gets saved into the .emacs.d/custom.el), but when emacs is
restarted, it cannot find the theme, presumably because custom.el
is loaded before the my customization file. Standard themes work
fine.

Re: customize-themes doesn't allow backquote or :inherit

[David De La Harpe Golden]

On 18/10/10 18:54, Yavuz wrote:
> Thinking a bit laterally, there are 2 alternate mechanisms that
> could help (at the loss of some flexibility):
>
> 1. There are named colors, such as "royal blue" that one can use
> instead of "#RRGGBB" format. If it were possible to user-define
> more, that would be a solution.

This is possible on X11, but not in the manner you mean: Those named 
colors are actually provided by the system.

Emacs bundles a copy of a historic de-facto standard set of named colors 
for non-x11 use.  The set of named colors adopted by modern web browsers 
was also largely based on that set, with some small changes [1].

However on real X11 (at least x.org and friends), the set of named 
colors is user-extensible e.g.  if you place the following in  ~/.xcms.txt

XCMS_COLORDB_START 0.1
Blobby	RGB:7fe2/ffe1/331a
XCMS_COLORDB_END

and then

export XCMSDB=~/.xcms.txt

and run emacs in that environment, you'll have the color "blobby" 
available in emacs (and any other x11 app which uses the relevant x11 
color api).

None of that means emacs couldn't support internal user-defined named 
colors, or any number of other things [2], just pointing out where they 
currently come from.


[1] http://en.wikipedia.org/wiki/X11_color_names

[2] e.g. I suggested - not too seriously - note the "may be 
overcomplicating things" - an ability to indirect through alists when 
resolving colors last time the matter came up:
http://lists.gnu.org/archive/html/emacs-devel/2009-08/msg00124.html