Re: risky local variable mechanism

[Richard M. Stallman]

       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.

    If the current risky-local-variable-p is too unreliable for
    `enable-local-eval' to such a degree that an urgent fix is needed, is
    it really reliable enough for unsafep?

Maybe it isn't.  However, it is not necessary for unsafep to be completely
as strict as the local variable criteria in all ways, because unsafep
checks for function values.

Meanwhile, as regards the special meaning of nil as the second
arg to risky-local-variable-p, we could instead have a variable
risky-local-variable-token, whose value is a particular cons cell,
and give that cons cell the special meaning of "unspecified value".

The value that hack-one-local-variable produces is made by `read'
so it will never be eq to risky-local-variable-token.