手动管理package的配置应该在elpa配置之前还是之后?

我现在是混用手动管理和package.el的。手动管理的代码仅仅是几行自动添加load-path的代码。那么这些代码最好放在package.el配置的前面还是后面?

谢谢

我放在package-initialize之后

不过, 怎么放有很大的区别么

只是因为我现在对Emacs的启动流程还是不了解……

如果手动和自动管理都有这么个package,先加载哪个?我主要担心这个问题

查gnu emacs reference吧

jugelizi

说实话我就是不明白这个优先级该怎么排。就是应该让自己手动管理的优先,还是package.el的优先。

我看到各大配置对此的处理都是不尽相同的。

各个配置的load-path里的顺序:

Spacemacs: 典型的根据layer来……在单个layer中,build-in,local的package在elpa的package之后被添加。也就是local的package的path在load-path里更靠近头部。从头至尾是local--elpa--local--elpa这么排的。

doom: 这个真不知道……

purcell: site-lisp在elpa之前被添加,更靠近尾部。

@seagle0128 你的配置是把lisp和site-lisp都放在load-path的最前面了?

是的,放到最前面可以节省20%的启动时间。其他的都由package包管理。

我看了一下,我和你对site-lisp的用途可能不同……

我的设置是如果site-lisp里没东西,就不添加到load-path

这个没有本质的区别吧。如果site-lisp没有东西,启动也不会耗费扫描时间;启动后随时放入新包,load-path也能找到。最最重要的就是lisp文件夹一定要在最前面,因为启动时会频繁的扫描load-path里的每个文件,如果靠后会耗费大量时间。

细节可以参考 仿照Doom-emacs的方式优化配置? · Issue #37 · seagle0128/.emacs.d · GitHub 。也是坛子里的XD 提的 issue,我作了相应优化。Chenbin 的配置也改成了相同方案。

我倒不关心这些速度的问题,我现在闹不明白这个逻辑……如果有函数覆盖,是该让手动管理的package覆盖自动管理的,还是相反?

其实这个看个人取舍,没有绝对对错。给点个人建议吧。

如果你自己管理的 package 和自动管理的 package 有功能或者函数相同,那显然你是想以自己管理的为主,否则就没有存在的必要,对吧?这样理解的话肯定是以本地自己管理的为准。虽然个人并不赞同这样做。

如果有了自动管理的package,只是因为某些 feature 或者 issue 需要覆盖掉自动管理的 package,那么用hook或者advice HACK 掉原有的功能就好。相应的给上游提交 issue或者 PR,等修复后这些 hack 或者 workaround 就可以去掉了。根据我的经验,管理多份相同功能的 package 真的很耗费精力,有时根本搞不清哪里出错了。与其这样不如fork 出来就自己管理,去掉自动管理的那份。当然,merge 也有工作量。

这也是为什么我会将lispsite-lisp放前面加载的原因之一:以自己的配置为准。

其实我发现不仅是你,doom, spacemacs以及redguardtoo/emacs.d的作者都是这样的观点……

但是purcell和prelude的作者的观点就完全相反……

但是如果不加载任何package,emacs的默认其实是site-lisp--lisp--lisp下的子文件夹。当然如果有package.el的情况下,就是elpa放最头部的位置。

所以这些东西的先后到底有没有理由,我就很困扰……毕竟我真的有点强迫症

你自己用 当然是自己的包优先

给别人用 那就系统的包优先呗

你替别人考虑下 别光想自己就不困扰了

有一点我觉得需要澄清下,包的加载顺序并不能决定最后到底是哪个起作用。hook、advice 等相互作用其实蛮复杂。site-lisp 的目的就是存放个人或者第三方的包,是系统包没有的功能或者是希望最后起作用的包,否则这个包没有必要存在。

没必要纠结,选择一种自己能接受的观点即可。

这我知道。不能依赖这个机制控制package的加载与否。

我还是决定跟你一样……我发现用你的方式确实能带来可见的速度提升……谢谢

而且我也得考虑一个问题就是……谁会闲着没事儿放俩一模一样的package玩……

就是啊,呵呵~~~终于有结论了,哥们处女座滴:joy: