如何在我的主模式钩子中访问目录本地变量？

Question

我已经定义了一个.dir-locals.el文件，其内容如下：

((python-mode . ((cr/virtualenv-name . "saas"))))

在我的.emacs文件中，我有以下函数来获取这个值并提供一个虚拟环境路径：

(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列表中，我有这个hook函数：

(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”。

很明显这里存在加载顺序问题；是否有一种方法可以使我的模式钩子语句响应目录本地变量？

- Chris R

Answer 1

这是因为normal-mode按照顺序调用了(set-auto-mode)和(hack-local-variables)。

但是hack-local-variables-hook会在本地变量处理完之后运行，这就可以采用一些解决方案：

1. 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.)

2. 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
   

   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.

3. 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)))
       ...))
   

   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.

   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?

- phils

---

也许你可以从你的钩子中调用（hack-local-variables）？ - Lindydancer

真的看不出方法2有什么缺点。 - Michael Livshin