[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: risky local variable mechanism

From: Chong Yidong
Subject: Re: risky local variable mechanism
Date: Sat, 11 Feb 2006 12:08:04 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Jonathan Yavner <address@hidden> writes:

> (re: mechanism proposed by Chong Yidong)
> unsafep.el (used by SES) calls risky-local-variable-p with NIL as the 
> second argument, because it doesn't know yet what value will be 
> assigned.  Please maintain the feature that NIL as second argument to 
> risky-local-variable-p means "There exists at least one risky value 
> that could be assigned to this variable."

Currently, `risky-local-variable-p' returns t if

 (1) The variable's `risky-local-variable' property is non-nil, or
 (2) The variable's name ends with "hook(s)", "function(s)", etc.,
     unless `safe-local-variable' is non-nil, or
 (3) The variable's `safe-local-variable' property is a function that
     evaluates to nil when given VAR as an argument.

My patch removes condition (3).  The idea is that the
`safe-local-variable' property can make a variable safe; it doesn't
make it risky.  Since SES does not use the `safe-local-variable'
property, SES will be completely unaffected.

(In the first place, the `safe-local-variable' property isn't used
much -- pre-patch, the only place in the Emacs tree that sets it is
files.el, in which we set compile-command to be always safe.)

An orthogonal question is whether risky-local-variable-p has any use
if we implement a whitelist.  The current behavior, in the patch I
posted, is that when the user presses `!' to save a set of local
variables (so that Emacs will allow those values in the future), risky
variables won't be saved.  This seems like annoying behavior.  Why
should we forbid the user from saving if he explicitly says to save?
We can change this so that even risky variables will be saved.  But
this makes risky variables just like every other variable that is not
marked safe.  One solution is to to keep `risky-local-variable-p'
around for unsafep.el to use, but not actually use it in
files.el---and just rely on the whitelist mechanism.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]