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

["Ken Manheimer" <ken.manheimer@gmail.com>]

in many cases, the qualifying criteria is already present, in the form
of the custom-type information:

On 4/20/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >     If we disallow t and want a quick&dirty replacement predicate for boolean
> >     values, we can either introduce booleanp (seems like a good predicate to
> >     have around anyway) or just use symbolp.
> [...]
> > I don't see any great need to eliminate t as a value,
> > and certainly not at the cost of any real annoyance.
>
> The intention is to force the author to think about which predicate to use,
> in the hope it will reduce the number of cases where the safe-local-variable
> predicate ends up accepting unsafe values as well.

seems to me we're heading down the road of duplicating the mechanisms
of the custom type system, and that we should be using it.  i strongly
suspect that the custom types of customizable variables are
appropriate as safety criteria in many cases, as well.  we wouldn't
want to assume that, but i suspect it would be very useful to make it
easy for authors to use the custom-type criteria for this purpose.

i'm thinking something along the lines of:

(defun qualify-value-by-custom-type (symbol value)
  "True if SYMBOL's type constraint is satisfied by VALUE."
  (let ((custom-type (get symbol 'custom-type))
        type)
    (when custom-type
      (setq type (widget-convert custom-type))
      (widget-apply type :match value))))

and have that function used when the `safe-local-variable' property
value is `t'.  the author can still specify alternate criteria if the
custom-type criteria is not suitable, or if the variable is state
rather than a customized.

this scheme would work just right for my allout safe-local-variables -
14 are customizable, where the custom-type criteria are just right for
the safety spec, and 3 are state vars, where i need to designate the
criteria.  when i do need to designate the criteria, i would like to
be able to use the expressiveness of the custom type system.  (it
already provides a boolean criterion, and everything else you could
need, like composition, etc.)

the one catch is that the customizable variables would have to be
autoloaded to have the custom information to test against - that seems
like the right thing to do, but would require code changes.

what do you think?
--
ken manheimer
ken.manheimer@gmail.com
http://myriadicity.net