Today on my Win2K machine at work, I opened a file containing the
# Local Variables:
# eval: (shell-script-mode)
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
(if (and (not (zerop (user-uid)))
(or (eq enable-local-eval t)
(set-window-start (selected-window) (point)))
(y-or-n-p (format "Process `eval' or hook local variables in file %s? "
(if (eq var 'eval)
(save-excursion (eval val))
(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.