Re: allout patch - more safe-local-variables, plus autoloads

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

> I see that you've used t as the property value.
> That allows any type of value.

> Most of these variables are supposed to be strings.
> I don't know what would happen if they were set to other types;
> did you check each one?

> It would be safer to use stringp as the property value
> for a variable that is supposed to be a string.

BTW, I thought we had decided not to support the special case t to mean "any
value is safe" and instead force the use of explicit predicates (which can
still be (lambda (x) t), of course: you can make it harder for people to
shoot themselves in the foot, but you can't prevent them from doing so if
they're sufficiently motivated).

Shouldn't we do that (basically the patch below, plus many other patches to
fix all the places where we use t).


        Stefan


--- files.el	13 avr 2006 10:22:03 -0400	1.826
+++ files.el	18 avr 2006 09:10:34 -0400	
@@ -2643,15 +2643,11 @@
  * There is a matching entry (SYM . VAL) in the
    `safe-local-variable-values' user option.
 
- * The `safe-local-variable' property of SYM is t.
-
  * The `safe-local-variable' property of SYM is a function that
    evaluates to a non-nil value with VAL as an argument."
   (or (member (cons sym val) safe-local-variable-values)
       (let ((safep (get sym 'safe-local-variable)))
-	(or (eq safep t)
-	    (and (functionp safep)
-		 (funcall safep val))))))
+        (and (functionp safep) (funcall safep val)))))
 
 (defun risky-local-variable-p (sym &optional ignored)
   "Non-nil if SYM could be dangerous as a file-local variable.