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

[Glenn Morris]

Stefan Monnier wrote:

>>> 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.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
[...]
> 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))))))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Does not compute.

Anyway, that would work, tho' perhaps it could just be hard-coded in
hack-one-local-variable-eval-safep, since the safety of mode: is not
customizable at present, and having hooks with non-empty defaults is
sub-optimal.

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

FWIW, I checked loaddefs.el without and without this change, and saw
only the expected differences.

>> + :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.

The only reason I could see needing :safe as an argument was if someone
had some hypothetical minor-mode that for some reason was not safe. In
which case, passing ":safe nil" seems like the simplest thing to me,
rather than eg ":safe 'no", or inverting the whole thing to use :risky
instead of :safe.

But, there's no option to do this with mode:, so this is not needed to
replace mode: for minor-modes.