Re: Risky local variable mechanism

[Chong Yidong]

> Even for the list of safe vars, there's a significant problem: future
> Emacsen may change (typically extend) the possible values of a var and/or
> their meaning, so that a safe var may become unsafe.
>
> I think we should only use `safe-variable' symbol-properties (only expected
> to be set by maintainers, and which can be removed/refined if necessary) and
> then for each var, an additional list of values which are considered safe
> (this can be set by users, or even automatically set when the user answers
> the interactive question).

I don't see how this would help.  As long as it is possible for a user
to explicitly set a variable as safe, there will be some sort of risk
of this sort.  (For example, regarding your idea, I could put on my
"anal retentive" hat and argue that previously safe values could turn
into unsafe ones in future Emacsen ;-)

Generally, I'm dubious about introducing any sort of complexity into
the local variables system, since, in practice, one only encounters a
rather small set of local variables which are generally obviously
safe.

> BTW, maybe the interactive question should allow more than 2 answers:
> - refuse those local variable settings this time.
> - refuse them now and every time in the future.
> - (maybe) refuse them in this Emacs session.
> - accept them but just this one time.
> - accept them every time.
> - (maybe) accept them just for this Emacs session.
> This way, there's still only one prompt.

I also thought of this, but couldn't find a good way to fit multiple
choices onto a single prompt.  Is there an example of this kind of
prompt elsewhere in Emacs?