[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The `risky-local-variable' blacklist
From: |
Davis Herring |
Subject: |
Re: The `risky-local-variable' blacklist |
Date: |
Tue, 31 Aug 2004 17:18:16 -0600 (MDT) |
> You do not understand. I was speaking very specifically about the
> timeclock-mode-string. My comments only apply to variables used as
> mode-line-string.
Ah -- the actual mode-line, not the "line in a file that sets the mode".
Oops.
> I don't think you understand the reason why timeclock-mode-string was not
> dangerous before: timeclock-mode-string can have a value of the form
> (:eval <foo>) which means "evaluate <foo> to get the string to display".
> So there's clearly something dangerous here. Such evalution-in-mode-string
> is new in Emacs-21, so most foo-mode-line-string variable have suddenly been
> made dangerous. Instead of going through all those vars and marking them
> risky, Emacs-21 decided that "if the var is not marked `risky', then ignore
> any of those new :eval special forms". I.e. it's safe either way. but in
> order to be able to use the new feature, you need to mark the var as
> "risky".
The documentation I have for `mode-line-format' has a slight bug, then. It
says that "For a symbol, its value is used (but it is ignored if t or
nil)."; it does not say that the symbol's value is processed recursively
(as it does for the other things that are re-interpreted). The Elisp
manual does describe the double-evaluation; should the docstring be
changed?
> I didn't discuss your general point about risky variables (because I mostly
> agree with it).
Well, I'm glad something I said made sense. Sorry that the rest was
noise.
Davis Herring
--
This product is sold by volume, not by mass. If it seems too dense or too
sparse, it means mass-energy conversion has occurred during shipping.