bug#8613: "mode:" for minor-mode breaks set-visited-file-name

[Stefan Monnier]

>> Not a bad idea, tho I'd much rather add
>> a (run-hook-with-args-until-success 'safe-local-eval-functions)
>> instead rather than rely on regexps.
> Regexps were the only way I could think of that did not require changes
> to the definition of each minor mode, however...

With a safe-local-eval-functions, you can do

(add-hook 'safe-local-eval-functions
          (lambda (form)
            (and (null (cdr form))
                 (symbolp (car form))
                 (string-match "-mode\\'" (symbol-name (car form))))))

>> Another option is to let define-minor-mode place
>> a `safe-local-eval-function' property on the minor-mode's symbol.

> ... that's nice and simple (I didn't know `safe-local-eval-function'
> existed); but I had to tweak make-autoload to get it to work right with
> autoloaded minor-modes (eg outline-minor).


> *** lisp/emacs-lisp/autoload.el      2011-05-04 15:38:41 +0000
> --- lisp/emacs-lisp/autoload.el      2011-05-05 02:14:30 +0000
> ***************
> *** 190,195 ****
> --- 190,197 ----
>              (if (member ',file loads) nil
>                (put ',groupname 'custom-loads (cons ',file loads))))))
>   
> +      ((eq car 'put) form)
> + 
>        ;; nil here indicates that this is not a special autoload form.
>        (t nil))))

Hmm... that will affect the (push (nth 1 form) autoloads-done).
Not sure if it matters.

> *** lisp/emacs-lisp/easy-mmode.el     2011-01-25 04:08:28 +0000
> --- lisp/emacs-lisp/easy-mmode.el     2011-05-05 00:44:36 +0000
> ***************
> *** 115,120 ****
> --- 115,122 ----
>   :lighter SPEC       Same as the LIGHTER argument.
>   :keymap MAP Same as the KEYMAP argument.
>   :require SYM        Same as in `defcustom'.
> + :safe PROP  Set the MODE function's `safe-local-eval-function' property
> +             to PROP (default t).

Not sure if we need it (currently all the -mode functions are presumed
safe when called without argument, as in the "mode:" cookie).
But if we do need it, it's better to reverse the meaning since we
should usually aim to make ":prop nil" behave the same as when
it's absent.


        Stefan