Re: Risky local variable mechanism

[Stefan Monnier <monnier@iro.umontreal.ca>]

> After realizing what we are really trying to do, I believe that this
> makes little sense.

Agreed.

> Also, the involved defcustom's are _very_ problematic.  The many Custom
> problems regarding listvars I mentioned earlier are _not_ minor.
> For instance, one serious problem is that if one would, for a
> subsequent Emacs version, _have_ to add variables to the default of
> one of these defcustoms, because these variables are obviously safe
> and often encountered, or much worse, obviously extremely dangerous,
> then any user who customized them in the prior version will never get
> his customized values updated, which may be very dangerous, if some
> very dangerous new variable was introduced.

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).

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.


        Stefan