emacs 模式特定的自定义键绑定(bind) : local-set-key vs define-key

Question

几年后定制我的.emacs文件，我发现我使用了两种不同的
设置主要模式特定键绑定(bind)的各种构造:

1. 使用钩子(Hook)和 local-set-key .例如:

(defun my/bindkey-recompile ()
  "Bind <F5> to `recompile'."
  (local-set-key (kbd "<f5>") 'recompile))
(add-hook 'c-mode-common-hook 'my/bindkey-recompile)

我会说这个结构可以很容易地使用相同的键绑定(bind)
通过向所有相关的主模式添加相同的功能来不同的主模式
钩子(Hook)(换句话说，“我想要哪些键绑定(bind)”是明确分开的
来自“我想要它们的模式”)。但是，我不习惯
事实上，这种定制是在缓冲区级别完成的，而我会
认为它们属于主要模式。

2. 使用 define-key (通常与 eval-after-load 结合使用以延迟
评估，直到加载相关的键盘映射)。例如:

(eval-after-load "cc-mode"
  '(progn
     (define-key c-mode-map   (kbd "C-c o") 'ff-find-other-file)
     (define-key c++-mode-map (kbd "C-c o") 'ff-find-other-file)))

相比之下，这个结构自定义了主模式本身，但更少
灵活:如果我想为另一种模式使用相同的键绑定(bind)，我将有
找到此模式的正确文件和键盘映射名称，并且几乎重复 eval-after-load表达式(尽管这可能是自动化的
一个函数/宏)。

问题:尽管这两种构造类型都运行良好并产生了我的结果
想要，它们在技术上非常不同，设置键绑定(bind)
不同时间的不同键盘映射。所以我的问题是:在这两个中
构造，是否有“首选/更好”的做事方式？ (或者也许是“最好的”
构造是我不知道的第三个？)

通过“首选/更好”，我的意思是:

不太容易与新的 emacs 版本发生冲突

不太容易受到主动次要模式的干扰/干扰

更惯用/可读/可与他人分享

Answer 1

我相信您描述的两种方法并没有您想象的那么不同。

请注意 local-set-key实际上评估 (define-key map key command)在哪里 map是 (current-local-map) 的值，通常由主要模式设置。

因此，尽管他们可以做不同的事情；大多数时候，唯一真正的区别是带有 local-set-key 的钩子(Hook)函数。 call 将重复/冗余地设置同一个键，而另一种方法只设置一次。

您可以使用 local-set-key 向自己展示这一点。在模式 Hook 中，在使用后删除该 Hook 函数，然后在相同的主要模式下创建一个新缓冲区，并测试绑定(bind)。

less prone to break with new emacs versions

我想您可能会争辩说，键盘映射的名称将来可能会更改，因此不需要知道名称是一个优势，但您同样可以说模式 Hook 的名称可能会更改。我认为这两者都不足以令人担忧。

需要注意的一件事是 local-set-key即使主模式没有建立 current-local-map 也可以工作，我想这使得它就广义方法而言更加健壮。

less prone to disturb/be disturbed by active minor-modes

没有区别。所有次要模式键盘映射优先于所有主要模式键盘映射，并且这两种方法都不会对 minor-mode-map-alist 的顺序产生任何影响(确定次要模式键盘映射的优先级)。

more idiomatic / readable / shareable with others

它们在我看来都是完全可读的，所以我在这方面也无法区分它们。

我说在每种情况下都使用对您来说最好的方法。我确实认为为了代码的一致性而对大多数事情采用标准方法是件好事，但我怀疑选择哪一个并不重要。显然，通过不不必要地评估相同的代码可以节省一些 CPU 周期，但这应该无关紧要。

我认为最明显的一种情况是你已经提到的那种——如果你想使用一个通用钩子(Hook)将相同的绑定(bind)应用于多个模式(但不是所有模式——为此我完全推荐 creating a custom minor mode )，然后是 local-set-key在那个钩子(Hook)内绝对是要走的路。