Re: risky local variable mechanism

[Chong Yidong]

> it is not clearly right for unsafep to reject binding all variables
> that would be rejected in a local variables list, given that unsafep
> can detect giving functions as values.

The commentary section of unsafep.el says:

  ;; A temporary binding is unsafe if its symbol:
  ;;  1.  Has the `risky-local-variable' property.
  ;;  2.  Has a name that ends with -command, font-lock-keywords(-[0-9]+)?,
  ;;      font-lock-syntactic-keywords, -form, -forms, -frame-alist, -function,
  ;;       -functions, -history, -hook, -hooks, -map, -map-alist, -mode-alist,
  ;;       -predicate, or -program.

This is exactly the definition of risky variables in my patch.  In
fact, the *current* definition of risky-local-variable-p does not
match this definition exactly, since it also checks
`safe-local-property'.  (The way it checks it is rather inconsistent,
BTW, there is no way to distinguish between VAL=nil meaning "any value
of the variable" and VAL=nil meaning "the value nil is supplied" when
`safe-local-property' is a function.  So if unsafep.el relied on this,
it was relying on a bug).

Maybe the commentary section of unsafep.el is wrong, and the latter
definition is intended.  But according to the docstring of
`unsafep-variable', it is supposed to detect if a variable is "safe as
a let-binding" -- no mention of file local variables there.

To clarify this issue, I'd like to ask: what's the specific goal of
unsafep.el?  Can anyone come up with a precise example of a problem
with using unsafep.el resulting from the proposed changes to the file
local variables code?  With a specific example, we can look into how
to adapt unsafep.el; otherwise, we're just going around in circles.

(Since SES seems to be the only package that uses unsafep.el, it looks
like the example will have to come from there.)