Today on my Win2K machine at work, I opened a file containing the following lines: # Local Variables: # eval: (shell-script-mode) # End: And got this message: Ignoring `eval:' in file's local variables "WTF?", I thought. After checking the relevant variables, I went to the source, and lo and behold, in files.el I found the following hunk of code: (if (and (not (zerop (user-uid))) (or (eq enable-local-eval t) (and enable-local-eval (save-window-excursion (switch-to-buffer (current-buffer)) (save-excursion (beginning-of-line) (set-window-start (selected-window) (point))) (setq enable-local-eval (y-or-n-p (format "Process `eval' or hook local variables in file %s? " (file-name-nondirectory buffer-file-name)))))))) (if (eq var 'eval) (save-excursion (eval val)) (make-local-variable var) (set var val)) (message "Ignoring `eval:' in file's local variables"))) "Hmm, I wonder what (user-uid) evaluates to on a Windows box?". Eventually, I found that I could tweak the value of nt-fake-unix-uid, which defaults to 0 (effectively root). From nt.c: *Set uid returned by `user-uid' and `user-real-uid'. Under NT and 9x, there is no uids, and even no almighty user called root. By setting this variable, you can have any uid of choice. Default is 0. Changes to this variable take effect immediately. Now, I understand why we disable local-eval when we're running as root, but is there any really compelling reason why by default we should not do local-eval under Windows? I have solved my problem by setting nt-fake-unix-uid, but won't many new windows users stumble across this problem? Do you think I should: a) change the default value of nt-fake-unix-uid b) put an explicit note in the docstring of enable-local-eval explaining this Windoze Weirdness(TM), or c) do nothing I'm open to suggestions. - Vin