emacs - 切换主要模式时如何保留目录局部变量？

Question

我致力于一个标准缩进和制表符为 3 个字符宽的项目，它混合使用了 HTML、PHP 和 JavaScript。由于我对所有内容都使用 Emacs，并且只想要该项目的 3 字符缩进，因此我在项目的根目录下设置了一个“.dir-locals.el”文件以应用于其下的所有文件/所有模式:

; Match projets's default indent of 3 spaces per level- and don't add tabs
(
 (nil .
        (
         (tab-width . 3)
         (c-basic-offset . 3)
         (indent-tabs-mode . nil)
         ))
 )

当我第一次打开文件时，它工作正常。切换主要模式时会出现问题 - 例如，在 PHP 文件中处理一大块文字 HTML。然后我丢失了所有 dir-local 变量。

我还尝试明确说明我在“.dir-locals.el”中使用的所有模式，并将“dir-locals-set-class-variables/dir-locals-set-directory-class”添加到我的 .emacs 文件中”。我很高兴地说它们都表现一致，最初设置 dir-local 变量，然后在我切换主要模式时丢失它们。

我正在使用 GNU Emacs 24.3.1。

在切换缓冲区的主要模式时重新加载 dir-local 变量的优雅方式是什么？

-- 编辑 -- 感谢 Aaron 和 phils 的出色回答和评论!在这里发帖后，我认为它“闻起来”像一个错误，所以输入了一份给 GNU 的报告——将向他们发送对这些讨论的引用。

Answer 1

根据对 Aaron Miller 的回答的评论，这里概述了调用模式函数时发生的情况(并解释了派生模式)；手动调用模式与 Emacs 自动调用模式有何不同；哪里after-change-major-mode-hook和 hack-local-variables在以下建议代码的上下文中适合于此:

(add-hook 'after-change-major-mode-hook 'hack-local-variables)

访问文件后，Emacs 调用 normal-mode它为缓冲区“建立了正确的主要模式和缓冲区局部变量绑定(bind)”。它通过首先调用 set-auto-mode 来做到这一点。 ，然后立即拨打 hack-local-variables ，它确定缓冲区的所有目录本地和文件本地变量，并相应地设置它们的值。

详情如何set-auto-mode选择调用方式，见C-hig (elisp) Auto Major Mode返回。它实际上涉及一些早期的局部变量交互(它需要检查 mode 变量，所以有一个特定的查找发生在模式设置之前)，但是“正确的”局部变量处理发生在之后。

当实际调用所选模式函数时，有一个值得详细说明的巧妙事件序列。这就需要我们稍微了解一下“派生模式”和“延迟模式 Hook ”……

派生模式和模式 Hook

大多数主要模式是用宏 define-derived-mode 定义的。 . (当然，没有什么能阻止您简单地编写 (defun foo-mode ...) 并做任何您想做的事情；但是如果您想确保您的主要模式与 Emacs 的其余部分完美兼容，您将使用标准宏。)

定义派生模式时，必须指定派生自的父模式。如果模式没有逻辑父级，你仍然使用这个宏来定义它(为了获得所有标准的好处)，你只需指定 nil为 parent 。或者，您可以指定 fundamental-mode作为父级，效果与 nil 的效果大致相同，我们马上就会看到。
define-derived-mode然后使用标准模板为您定义模式函数，调用模式函数时发生的第一件事是:

(delay-mode-hooks
  (PARENT-MODE)
  ,@body
  ...)

或者如果没有设置父项:

(delay-mode-hooks
  (kill-all-local-variables)
  ,@body
  ...)

如 fundamental-mode本身调用(kill-all-local-variables)然后在这种情况下调用时立即返回，将其指定为父级的效果相当于如果父级为nil .

请注意 kill-all-local-variables运行 change-major-mode-hook在做任何其他事情之前，这将是在整个序列中运行的第一个钩子(Hook)(并且它发生在前一个主要模式仍然处于事件状态时，在评估新模式的任何代码之前)。

所以这是发生的第一件事。 mode 函数所做的最后一件事是调用 (run-mode-hooks MODE-HOOK)为自己的 MODE-HOOK变量(这个变量名实际上是模式函数的符号名，带有 -hook 后缀)。

所以如果我们考虑一个名为 child-mode 的模式源自 parent-mode源自 grandparent-mode ，当我们调用 (child-mode) 时的整个事件链看起来像这样:

(delay-mode-hooks
  (delay-mode-hooks
    (delay-mode-hooks
      (kill-all-local-variables) ;; runs change-major-mode-hook
      ,@grandparent-body)
    (run-mode-hooks 'grandparent-mode-hook)
    ,@parent-body)
  (run-mode-hooks 'parent-mode-hook)
  ,@child-body)
(run-mode-hooks 'child-mode-hook)

什么delay-mode-hooks做？它只是绑定(bind)变量 delay-mode-hooks , 由 run-mode-hooks 检查.当此变量为非 nil 时, run-mode-hooks只是将它的参数推送到一个在 future 某个时间运行的钩子(Hook)列表，并立即返回。

仅当 delay-mode-hooks是 nil将 run-mode-hooks实际上运行钩子(Hook)。在上面的例子中，这直到 (run-mode-hooks 'child-mode-hook)叫做。

对于(run-mode-hooks HOOKS)的一般情况，以下钩子(Hook)依次运行:

change-major-mode-after-body-hook

delayed-mode-hooks (按照它们本来会运行的顺序)

HOOKS (作为 run-mode-hooks 的参数)

after-change-major-mode-hook

所以当我们拨打 (child-mode) ，完整序列为:

(run-hooks 'change-major-mode-hook) ;; actually the first thing done by
(kill-all-local-variables)          ;; <-- this function
,@grandparent-body
,@parent-body
,@child-body
(run-hooks 'change-major-mode-after-body-hook)
(run-hooks 'grandparent-mode-hook)
(run-hooks 'parent-mode-hook)
(run-hooks 'child-mode-hook)
(run-hooks 'after-change-major-mode-hook)

回到局部变量...

这让我们回到 after-change-major-mode-hook并用它来拨打 hack-local-variables :

(add-hook 'after-change-major-mode-hook 'hack-local-variables)

我们现在可以清楚地看到，如果我们这样做，有两种可能的音符序列:

我们手动改成foo-mode :

(foo-mode)
 => (kill-all-local-variables)
 => [...]
 => (run-hooks 'after-change-major-mode-hook)
     => (hack-local-variables)

我们访问一个文件，其中 foo-mode是自动选择:

(normal-mode)
 => (set-auto-mode)
     => (foo-mode)
         => (kill-all-local-variables)
         => [...]
         => (run-hooks 'after-change-major-mode-hook)
             => (hack-local-variables)
 => (hack-local-variables)

hack-local-variables是不是有问题跑两次？也许，也许不是。至少它的效率略低，但对于大多数人来说，这可能不是一个重要的问题。对我来说，最重要的是我不想依赖这种安排在所有情况下都很好，因为这肯定不是预期的行为。

(就我个人而言，我确实在某些特定情况下确实导致这种情况发生，并且它工作得很好；但当然这些情况很容易测试——而作为标准这样做意味着所有情况都会受到影响，而测试是不切实际的。)

因此，我建议对该技术进行小幅调整，以便在 normal-mode 时不会发生我们对该函数的额外调用。正在执行:

(defvar my-hack-local-variables-after-major-mode-change t
  "Whether to process local variables after a major mode change.
Disabled by advice if the mode change is triggered by `normal-mode',
as local variables are processed automatically in that instance.")

(defadvice normal-mode (around my-do-not-hack-local-variables-twice)
  "Prevents `after-change-major-mode-hook' from processing local variables.
See `my-after-change-major-mode-hack-local-variables'."
  (let ((my-hack-local-variables-after-major-mode-change nil))
    ad-do-it))
(ad-activate 'normal-mode)

(add-hook 'after-change-major-mode-hook 
          'my-after-change-major-mode-hack-local-variables)

(defun my-after-change-major-mode-hack-local-variables ()
  "Callback function for `after-change-major-mode-hook'."
  (when my-hack-local-variables-after-major-mode-change
    (hack-local-variables)))

这样做的缺点？

主要的一个是您不能再更改使用局部变量设置其主要模式的缓冲区的模式。或者更确切地说，它将作为局部变量处理的结果立即变回。

这并非不可能克服，但我暂时将其称为超出范围:)