Re: enable-local-eval in Windows
On Fri, 24 Jan 2003, acs(a)xemacs.org wrote:
Today on my Win2K machine at work, I opened a file containing the
following lines:
# Local Variables:
# eval: (shell-script-mode)
# End:
Of course, you didn't really need to use eval here to set the mode,
but you know that...
And got this 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.
Cool - I just smashed the function when I ran into it.
(when (and (eq system-type 'windows-nt) (zerop (user-uid)))
(defun user-uid () 1))
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
Changing the default value of nt-fake-unix-uid sounds reasonable to
me... Windows 95/98/ME doesn't have much of a concept of user or
root, so uid/user doesn't mean anything, right? Maybe Windows
NT(etc) has a more useful concept of user and admin, that would allow
a better implementation of uid.
While we're at it, there are some class of functions that are
reasonable to do inside of an eval. For example, I wanted web
addresses highlighted in a text file, so I did eval: (goto-address)
But in order to get the local-eval to stop asking or to happen at all
on windows, I had to advise hack-one-local-variable:
;;1 -> hack-one-local-variable: var=eval val=(goto-address)
(defadvice hack-one-local-variable (around goto-address-ok first activate)
(let ((enable-local-eval (if (equal val '(goto-address)) t enable-local-eval)))
ad-do-it))
Maybe we could have a local-eval-expressions customization (say an
alist of expressions with nil/:ask/t values) that allows the user to
explicitly say that certain eval expressions that are ok. This check
could be done before checking for (zerop (user-uid)). Basically, any
minor-mode function is, or should be, ok in a :eval.
-jeff