纯手工 git submodule 并不麻烦， 开始加一次 git url 就好了。
以后想升级的时候， 切换到插件目录 git pull 就好了， 而且最新版有问题， 可以执行 git reset 随时切换会稳定的版本。
git submodule 是生产力稳定使用最好的方式。
最大的好处就是， 再也不用焦虑升级后会不会挂的问题。
1 个赞
确实是的。Borg 也是用 git submodule 来实现的。
我上面说的麻烦是指处理 byte-compile，autoload，文档的编译等等。 或者就是要放弃这些。
byte-compile 我觉得完全没必要， 因为Emacs的性能瓶颈不在这里。
手动写 autoload 太废事情了， 用 lazy-load 类似的技术做最简单， 自定义按键的时候顺便 autoload 就自动做了。
文档的编译， 没看懂是啥， 一般直接看elisp插件源代码最快。
就是有的包会提供 .texi 格式的文档，编译后，可以通过 C-h i 查看包的文档，和内置的包一样。比如，magit 就提供了 magit.texi
确实我很多时候也是直接去看源码，源码中的函数也有文档。
这也是一个不错的方法
你一旦用习惯了 git submodule ， 就发现Emacs各种包管理的功能都没有git做的好。
1 个赞
byte compile 可以有效减少执行函数时的 GC 次数，代码写得好的提升还是明显的，如果过度使用函数来抽象的话就是如编了
autoload 也是可以自动生成的。
不过我个人用的方法是把所有需要手动安装的 el 文件装到一个路径下，生成一个 autoload 文件，然后配置只要加载这一个文件就够了，减少 load-path 相当给加载文件加速了。Emacs 内置的包也是用这样的方法加载的。
编译 texi 需要的是 GNU texinfo，变成 info 文件后安装，然后添加 info path 到 emacs 就行了
手写 makefile 足够用来管理这些了
大幅度提高性能目前最靠谱的就是像 lsp-bridge 这样把大量对象的计算放到外部进程， 并利用外部进程的多线程做并发计算。
这样做， Emacs从根本上就不会产生大量计算过程中的对象，也就没有了GC操作， 所以我现在都不期待 byte compile 那点毛毛雨的提升。
同时Emacs除了GC， 影响用户体验的主要是多线程，只有大量计算的时候不要GC并提供多线程支持才是性能提升的关键。
综上所述， Emacs的性能提升在于对关键高性能插件的重点优化， 比如 LSP补全， 大规模模糊搜索，大量Overlay渲染， 多媒体计算等关键地方用外部进程优化后， 就不会卡。
3 个赞
我是用 git submodule 进行包管理的。以前为了实现 borg 提供的 autoload, byte compile 等功能，抄过它的源码，其实也不是很复杂……
关于 compile，我的做法是给部分包做 byte-compile，因为 byte-compile 还有个副作用是 natively-compile，后者的性能提升会更明显一些。org-mode, magit 这些包里的函数众多，本身对 byte/natively compile 的支持也比较好，我会选择编译一下，毕竟它们也提供了一键编译的 Makefile 文件。大多数包其实就没用到 compile，也是为了方便我随时去 submodule 里面改源码看看效果（不然还要删除 .elc 文件）。
关于 autoload，我也几乎很少用，因为 use-package 提供的 autoload 就够用了，一般我也不需要 autoload 某个包的所有函数。例如，对于 org-mode 你可能只需要 autoload 一个 org-mode 然后配置好 auto-mode-alist，访问 .org 文件时就会自动 (require 'org)，其他函数自然加载好了。不过如果有个包里确实有很多函数需要 autoload，或者有一些带 autoload cookie 的普通语句（一般是各种 major mode 中对 auto-mode-alist 的修改），我还是会选择 loaddefs-generate。
关于 .texi 文档，一般有提供的话，都会有 Makefile 一键编译为 .info，修改一下 Info-default-directory-list 即可。
3 个赞
改完 C-c C-f 就順手编译了
最近弃用了 doom emacs，改成手写配置了
4 个赞
速度吧？在 Windows 上, 以 git 為主的方式都很慢. 跟 magit 為什麼在 Windows 很慢是同個問題. 
Windows 上使用 straight.el…, 不知道該用什麼評價. 
1 个赞
从doom转向Centaur
各位逃离 Doom 是因为 Doom 开发停滞了吗？Doom的设计还是挺好的呀。
Doom 作者简直劳模，现在也没有开发停滞吧，近况说是在准备 3.0？
我离开 Doom 的原因还是因为想有一套自己如数家珍的配置，方便 debug 和修改。Doom 的魔法太多了。
2 个赞
是的 Doom 在开发3.0. 但这个 3.0 已经很久了，迟迟出不来。不过功能还是值得期待。Doom 魔法是有点多
但设计挺好，速度也高，社区人也多，比较活跃，看看那么多PR没有合并。 省的折腾有些不熟悉的插件，立马就能用。
是的，开箱即用，很适合用来安利 Emacs。
不过我觉得这种框架都是有充足的知识去使用才能发挥得比较好，而熟悉 Elisp 最快的办法就是跟着自己写一套配置🤣
我是因为doom更新总失败网络问题无法解决，加上更倾向于原生键位 
我是因为作者合并太慢，好像有时候一个月左右才出现一次合并下东西，然后就弃用了
因为我想写 elisp
移除了which-key，因为which-key最近成了emacs30内置包
1 个赞