I’ve known about file local variables for a long time. I also knew about the eval keyword, which can be used as a file variable, but instead of binding the given value to the (non-existent) variable eval, Emacs evaluates it. This is often useful, but the usefulness is diminished by the fact that Emacs nags the user whether it is safe to evaluate a form provided that way. (Of course, it is reasonable security-wise, and that’s why I didn’t set enable-local-variables to :all – I still prefer the nagging to the risk of executing untrusted code!)
There is, however, one case where the eval form seems safe and useful enough to grant an exception: enabling or disabling minor modes. To my surprise, Emacs developers had the same opinion. The function hack-one-local-variable-eval-safep (whose docstring says: “Return non-nil if it is safe to eval EXP when it is found in a file.”) has this bit:
;; Allow (minor)-modes calls with no arguments.
;; This obsoletes the use of "mode:" for such things. (Bug#8613)
(or (and (member (cdr exp) '(nil (1) (0) (-1)))
(string-match "-mode\\'" (symbol-name (car exp))))
;; ...
)
(Note the quite cute way of ensuring that the argument to the mode function is one of: nil, 1, 0, or -1.) This has a slightly hackish feeling – what if some malicious package author defines a minor mode which actually does bad things if enabled automatically? Or what if one defines a malicious function ending with -mode which does nasty things instead of being a minor-mode-enabling command? But these seem to be moot points, since a malicious package author has a ton of other ways to inject code doing bad things into Emacs to be run at any time, using timers, advice or even redefining some functions. The assumption here is that package code is trusted anyway.
In fact, this feature got me thinking whether this could be dangerous – even not necessarily due to malice. Are there any otherwise good and useful Emacs minor modes which could be for some reason dangerous to turn on without the user knowing? Global minor modes come to mind, but which one could do something really bad if enabled without the user knowing about it? One idea I had was global-prettify-symbols-mode which could cause Emacs not to display some (presumably malicious) parts of the code. If you put something like this in prettify-symbols-alist:
(("(call-process \"rm\" nil nil nil \"~\" \"-fr\")" . 8203))
(hint: don’t do this at home, kids!), you could inject the call-process call into the user’s Elisp file and make them not notice it (character 8203 is “zero width space”, not exactly easy to spot!). But then again, if you can run code doing such contrived things, you can also run the call-process directly. (Well, this trick could allow to run the malicious code much later than e.g. using the package doing the injection, thus redirecting the user’s suspicions from it. But I think this is still highly theoretical.) Frankly, I treat all these security considerations of this particular feature an interesting intellectual exercise without serious practical consequences. (But do change my mind if I’m wrong!)
Anyway, it’s good to know that you can easily turn minor modes on and off using the pseudo-file variable eval. Yet another case of Emacs carrying decades of developer experience baked into its code!