如何访问主模式挂钩中的目录局部变量？

Question

我定义了一个包含以下内容的 .dir-locals.el 文件：

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

在我的 .emacs 中，我有以下函数来检索该值并提供 virtualenv 路径：

(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 列表中，我有这个钩子功能：

(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< /代码>。然而，当我查看这个名字时，我得到的是“saas”。

显然这里存在加载顺序问题；有没有办法让我的模式挂钩语句响应目录局部变量？

Answer 1

发生这种情况是因为正常模式按顺序调用(set-auto-mode)和(hack-local-variables)。

然而 hack-local-variables-hook 是在处理局部变量之后运行的，这可以实现一些解决方案：

1. 第一个是让 Emacs 为每个主要运行一个新的“局部变量钩子”模式：

   (add-hook 'hack-local-variables-hook 'run-local-vars-mode-hook)
   (defun run-local-vars-mode-hook ()
     “在处理局部变量后运行主模式的钩子。”
     （run-hooks（实习生（concat（符号名称主要模式）“-local-vars-hook”））））
   
   (add-hook 'python-mode-local-vars-hook 'cr/python-mode-shell-setup)
   

   （使用这种方法，您的原始函数可以不加修改地使用。）

2. 是利用 add-hook 的可选 LOCAL 参数，使指定的函数成为缓冲区本地的。使用这种方法，您可以按如下方式编写钩子：

   (add-hook 'python-mode-hook 'cr/python-mode-shell-setup)
   
   (defun cr/python-mode-shell-setup ()
     （添加钩子'hack-local-variables-hook
               (lambda () (消息“virtualenv-name is %s”cr/virtualenv-name)
                 (让 ((python-base (cr/virtualenv)))
                   (cond ((and (fboundp 'ipython-shell-hook) (文件可执行文件-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）））））
               无 t)) ;缓冲区本地 hack-local-variables-hook
   

   ie python-mode-hook 首先运行，并仅针对当前缓冲区向 hack-local-variables-hook 注册匿名函数；然后在处理局部变量后调用该函数。

3. Lindydancer 的评论提出了第三种方法。它不像其他两个那么干净，但无论如何都证明很有趣。我不喜欢导致 (hack-local-variables) 被调用两次的想法，但我发现如果您设置 local-enable-local-variables本地缓冲区，它会阻止(hack-local-variables)做任何事情，所以你可以这样做：

   (defun cr/python-mode-shell-setup ()
     （报告错误“文件局部变量错误：%s”
       （黑客本地变量）））
     （设置（make-local-variable'local-enable-local-variables）nil）
     (let ((python-base (cr/virtualenv)))
       ...））
   

   显然，这会稍微修改正常的执行顺序，因此可能会产生副作用。我担心如果文件中的局部变量 comment 设置相同的主要模式，这可能会导致无限递归，但这实际上似乎不是问题。

   局部变量头注释（例如-*- mode: foo -*-）由(set-auto-mode)处理，所以这些都很好；但是 mode: foo Local Variables: 注释似乎是一个问题，因为它是由 (hack-local-variables) 处理的，因此，如果以这种方式设置模式，我认为它会导致递归。

   在实践中，我能够通过使用一个简单的函数作为“模式”来触发问题，该函数除了尝试运行其钩子之外什么也不做；然而，使用“正确”模式进行测试并没有出现问题，因此实际上可能是安全的。我没有进一步研究这个（因为其他两个解决方案比这个更干净），但我猜延迟模式挂钩机制可能解释了它？