change-major-mode-hook 似乎正在运行新的主要模式已经启用。在主模式发生变化之前如何运行一个函数？
示例：带有major-mode-abc 的缓冲区有minor-mode-xyz 处于活动状态，并且该次要模式负责放置某些覆盖。更改为major-mode-def 时，如果minor-mode-xyz 在更改主要模式之前处于活动状态，则必须执行函数remove-overlays。新的major-mode-def 也再次激活minor-mode-xyz 并立即绘制新的叠加层（这是一件好事）；然而，那些新的覆盖（我想保留的）被'change-major-mode-hook 'remove-overlays nil t 删除了。我宁愿 remove-overlays 函数使用与 minor-mode-xyz 关联的钩子运行，而不是作为启用 major-mode-def 的一部分。
【问题讨论】：
您说“change-major-mode-hook 似乎在...之后运行”：我想知道是什么让您这么认为，因为它是在 before 之前运行的，即它确实做了什么你在问（并且恰好用于这种情况）。
【讨论】：
change-major-mode-hook。非常感谢您的帮助 - 谢谢。
我可能误解了你的问题，但我在这里没有看到任何问题，假设你的次要模式是从主要模式挂钩中启用的，并将其清理功能添加到change-major-mode-hook。
change-major-mode-hook 在主模式函数的最开始运行，在其他任何事情之前，包括主模式挂钩。因此，您的次要模式的清理功能在之前被新的主要模式的钩子重新启用您的次要模式调用。如果这对您不起作用，则您的次要模式实现或设置中可能存在缺陷。
或者，您可以延迟将新叠加层添加到post-command-hook，而不是直接在次要模式函数中添加它们。定义一个缓冲区局部变量，并在您的次要模式函数中将该变量设置为非零值。然后将一个函数添加到缓冲区本地post-command-hook，如果变量非零，则添加覆盖。
这可以确保在新的主要模式完全设置之前不绘制覆盖，包括清理任何旧的覆盖。这种方法的另一个优点是叠加层的添加可以访问新主要模式的文件本地和目录变量。
【讨论】：
change-major-mode-hook。您是对的，因为我的次要模式设置存在缺陷。我在使用 (when (called-interactively-p 'any) . . . 启用次要模式时包装了覆盖功能，并错误地指责 change-major-mode-hook 擦除了我的新覆盖，而实际上这些新覆盖从未存在，因为从技术上讲，次要模式没有启用 交互（而是作为新的主要模式挂钩的一部分启用）。