如何在主模式挂钩中访问目录局部变量? [英] How can I access directory-local variables in my major mode hooks?
问题描述
我定义了一个 .dir-locals.el 文件，内容如下:
I have defined a .dir-locals.el file with the following content:
((python-mode . ((cr/virtualenv-name . "saas"))))
在我的 .emacs 中，我有以下函数来检索这个值并提供一个 virtualenv 路径:
In my .emacs I have the following function to retrieve this value and provide a virtualenv path:
(defun cr/virtualenv ()
(cond (cr/virtualenv-name (format "%s/%s" virtualenv-base cr/virtualenv-name))
((getenv "EMACS_VIRTUAL_ENV") (getenv "EMACS_VIRTUAL_ENV"))
(t "~/.emacs.d/python")))
最后，在我的 python-mode-hook 列表中，我有这个钩子函数:
Finally, in my python-mode-hook list, I have this hook function:
(add-hook 'python-mode-hook 'cr/python-mode-shell-setup)
(defun cr/python-mode-shell-setup ()
(message "virtualenv-name is %s" cr/virtualenv-name)
(let ((python-base (cr/virtualenv)))
(cond ((and (fboundp 'ipython-shell-hook) (file-executable-p (concat python-base "/bin/ipython")))
(setq python-python-command (concat python-base "/bin/ipython"))
(setq py-python-command (concat python-base "/bin/ipython"))
(setq py-python-command-args '( "-colors" "NoColor")))
(t
(setq python-python-command (concat python-base "/bin/python"))
(setq py-python-command (concat python-base "/bin/python"))
(setq py-python-command-args nil)))))
当我打开一个新的 python 文件时，cr/python-mode-shell-setup 记录的消息表明 cr/virtualenv-name 是 nil.但是，当我 C-h v 名称时，我会得到saas".
When I open a new python file, the message logged by cr/python-mode-shell-setup indicates that cr/virtualenv-name is nil. However, when I C-h v the name, I get "saas" instead.
显然这里存在加载顺序问题；有没有办法让我的模式钩子语句响应目录局部变量?
Obviously there's a load order issue here; is there a way to have my mode hook statements respond to directory-local variables?
推荐答案
发生这种情况是因为 normal-mode 调用了 (set-auto-mode) 和 (hack-local-variables) 的顺序.
This happens because normal-mode calls (set-auto-mode) and (hack-local-variables) in that order.
但是hack-local-variables-hook是在处理完局部变量之后运行的，这使得一些解决方案成为可能:
However hack-local-variables-hook is run after the local variables have been processed, which enables some solutions:
首先是让 Emacs 为每个主要模式运行一个新的局部变量挂钩":
The first is to make Emacs run a new "local variables hook" for each major mode:
(add-hook 'hack-local-variables-hook 'run-local-vars-mode-hook)
(defun run-local-vars-mode-hook ()
"Run a hook for the major-mode after the local variables have been processed."
(run-hooks (intern (concat (symbol-name major-mode) "-local-vars-hook"))))
(add-hook 'python-mode-local-vars-hook 'cr/python-mode-shell-setup)
(使用这种方法，您的原始函数可以不加修改地使用.)
(Your original function can be used unmodified, with that approach.)
第二个选项是使用可选的 LOCAL 参数给 add-hook，使指定的函数成为缓冲区本地的.使用这种方法，您可以按如下方式编写钩子:
A second option is to utilise the optional LOCAL argument to add-hook that makes the specified function buffer-local. With this approach you could write your hook as follows:
(add-hook 'python-mode-hook 'cr/python-mode-shell-setup)
(defun cr/python-mode-shell-setup ()
(add-hook 'hack-local-variables-hook
(lambda () (message "virtualenv-name is %s" cr/virtualenv-name)
(let ((python-base (cr/virtualenv)))
(cond ((and (fboundp 'ipython-shell-hook) (file-executable-p (concat python-base "/bin/ipython")))
(setq python-python-command (concat python-base "/bin/ipython"))
(setq py-python-command (concat python-base "/bin/ipython"))
(setq py-python-command-args '( "-colors" "NoColor")))
(t
(setq python-python-command (concat python-base "/bin/python"))
(setq py-python-command (concat python-base "/bin/python"))
(setq py-python-command-args nil)))))
nil t)) ; buffer-local hack-local-variables-hook
即python-mode-hook 首先运行并使用 hack-local-variables-hook 为当前缓冲区注册匿名函数；然后在处理完局部变量后调用该函数.
i.e. python-mode-hook runs first and registers the anonymous function with hack-local-variables-hook for the current buffer only; and that function is then called after the local variables have been processed.
Lindydancer 的评论提示了第三种方法.它不像其他两个那么干净，但无论如何证明很有趣.我不喜欢导致 (hack-local-variables) 被调用两次的想法，但我看到如果你设置 local-enable-local-variables本地缓冲，它阻止 (hack-local-variables) 做任何事情，所以你可以这样做:
Lindydancer's comment prompts a third approach. It's not nearly as clean as the other two, but proved interesting regardless. I didn't like the idea of causing (hack-local-variables) to be called twice, but I see that if you set the local-enable-local-variables buffer-locally, it prevents (hack-local-variables) from doing anything, so you could do this:
(defun cr/python-mode-shell-setup ()
(report-errors "File local-variables error: %s"
(hack-local-variables)))
(set (make-local-variable 'local-enable-local-variables) nil)
(let ((python-base (cr/virtualenv)))
...))
显然，这稍微修改了正常的执行顺序，因此可能会产生副作用.我担心如果文件中的局部变量 comment 设置了相同的主模式，这可能会导致无限递归，但这实际上似乎不是问题.
Obviously that modifies the normal sequence of execution a little, so side effects may be possible. I was worried that if the same major mode is set by a local variable comment in the file, this might cause infinite recursion, but that doesn't actually appear to be a problem.
局部变量头注释(例如-*- mode: foo -*-)由(set-auto-mode)处理，所以没问题；但是 mode: foo Local Variables: 注释似乎是一个问题，因为它由 (hack-local-variables) 处理，因此，如果以这种方式设置模式，我认为它会导致递归.
Local variable header comments (e.g. -*- mode: foo -*-) are handled by (set-auto-mode), so those are fine; but a mode: foo Local Variables: comment seems like it would be an issue as it is handled by (hack-local-variables), and so if the mode is set that way I thought it would cause recursion.
在实践中，我能够通过使用一个简单的函数作为模式"来触发这个问题，它只是尝试运行它的钩子；然而，使用正确"模式进行测试并没有出现问题，因此在现实中可能是安全的.我没有进一步研究这个(因为其他两个解决方案比这更清晰)，但我猜延迟模式钩子机制可能解释了它?
In practice I was able to trigger the problem by using a simple function as a 'mode' which did nothing more than try to run its hooks; however testing with a 'proper' mode did not exhibit the problem, so it's probably safe in reality. I didn't look into this further (as the other two solutions are much cleaner than this), but I would guess the delayed mode hooks mechanism probably explains it?
这篇关于如何在主模式挂钩中访问目录局部变量?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
