。。。。我的意思是安装插件的速度变快了
我知道你是这个意思，但是启动时间变慢了我接受不了
我67个包不到1秒，wsl下的
我现在384个包，0.14左右启动。如果不能支持batch，这个时间几乎需要翻3倍。
我之前总是会切换 emacs版本去体验，然后doom的下载包就很慢。所以我才中意elpaca.
换了，现在还挺方便，主要是新环境包下的太慢，这个并发就很快，之前的use-package基本无缝兼容，只是一些内置包，需要ensure nil下，其余基本不需要改，可以直接用
最近用nix 的 home-manager 管理emacs 包了，感觉也非常好用。
Windows 的支援怎麼樣？我之前試過 straight.el, 啟動或安裝在 Windows 上都慢上許多⋯ 這類型的套件看這麼多人在推，我卻完全無感 
windows是ok的
Elpaca 在 Windows 系统完全没有问题, 安装也快.
之前在 borg 和 elpaca 之间犹豫, 后面发现 elpaca 安装包时快得多, 貌似 elpaca 是并行安装的, 就选了 elpaca 了, 现在也有 lock-file 功能了.
对，尤其是国内的网不是很好，很容易安装失败，有了elpaca可以节省很多的时间
那啟動時間如何呢? 畢竟 Windows 啟動時間已經很慢了, 希望不要再慢下去. 
我接下來說的大概是個 unpopular opinion, 我認為 Elpaca 並不是個很好的包. 先說他的優點, 他對於一般 Emacs 使用者而言是極其美好的. 但是對於一些包的維護者來說是有一定程度上的影響, 我自己維護的包之前就有被提及說 elpaca 安裝失敗的問題, 貌似好像是依賴不再於使用者的 archives 的關係? (有點忘記了) 但這些明顯 package.el 所做的技術上的抉擇, 卻被 elpaca 的作者隱藏起來. 我不知道他是有知識上的缺漏, 還是刻意所為, 但這種行為會造成包維護者上的困擾. 例如: transient raises a `wrong-type-argument number-or-marker-p nil` when calling `magit-commit` · Issue #5329 · magit/magit · GitHub
因為之前看過很多類似這種帖, 讓我有點忍不住想講下. Elpaca 本質上是解決了問題, 但代價是隱藏了 package.el 重視的問題. 對於一般包的維護者, 肯定選擇兼容正式的安裝流程. 另一方面, Elpaca 和 straight.el 無疑是個注定沒有未來的選項 (除非之後被合併).
但我還是會支持作者繼續它的開發, 畢竟 Emacs 生態已經很小了, 既然有人覺得好用, 我覺得它自然就有它的價值在. 
- 启动速度估计是慢一点的, 但更多取决于个人配置.
- elpaca 安装某些确实有些问题, 比如安装 telega.el 时, 我有台电脑安装 telega.el 不完整(没细找问题).
- package install 这么多问题吗? 包本质难道不是 .el >> .elc 然后 autoload 就可以了吗?
我記得其中一個比較重要的是, 依賴的安裝/移除的順序 (thread-safe). 對於 elisp 這種環境來說, 這是個蠻困難的問題. 
加上 async 之後又更為複雜了, 我想這大概是為什麼很多人都有嘗試 async 包管理的包 (MELPA 上面至少有三個以上, feather.el, quelpa, 等等), 但依然沒能合併到主幹的其中一個原因. 至少需要不少的細部討論, 不敢貿然決定.
當然還有其他細節, 有的是 license issue, 或是歷史問題, 等等.
请问这些问题是elpaca用async的结果吗，还是包括straight在内也会有一样的问题？使用borg这种方式呢？
没有完全理解这个问题…
不是 elpaca 和 async 的问题, 是依赖的问题吧.
有些包依赖 async, 比如安装 feather 了, 但是 async 没有安装, 就导致错误表示没有找到 async 包
1 个赞
使用 borg 根本不关心这些的了, 缺什么就自己 clone 添加, borg 很简单就是将 仓库 clone 下来.
elpacca 异步加载包的设计我不是很喜欢。
这意味着你所有包的配置都得写成异步形式的，异步就比同步 debug 麻烦多了。也包括 profiling emacs的启动速度也麻烦多了。
其实异步装包和异步加载包完全是两码事，neovim 这边的包管理器如 lazy.nvim 就是异步多进程装包，但是加载包就是同步的。
elpacca 最大的优势就是装包非常快，但是本身装包也不会天天去装包，但是要比整个 config 的 结构都改变，异步的方式也很不直观。再加上 elpacca 在 lockfile 做的还是不如 straight 完善。所以还是我还是继续使用 straight。
straight是同步的。
我的使用体验下来 straight 几乎没遇到过包装不了的情况，除了懒猫开发的那些用python的包用straight会麻烦一些，但是那些包本身也没办法用package.el 装，最好的办法就是手动管理。
magit的这个问题我看了下好像是magit现在需要最新版的transient，但是elpacca因为安装包是 async的，所以在安装magit的时候使用的是内置的transient。但是 straight 因为是同步的，所以其实是没有这个问题的。
1 个赞
没有未来感觉有点夸张了啊哈哈哈。毕竟 emacs 已经这么小众了，要这么说 emacs 以后也没有未来了。另外 straight 毕竟是同步装包的，和 elpacca 是完全不一样的。你链接里提到的例子其实是 elpacca async 装包在实现上要 tricky 很多，作者存在并没有考虑周到的情况。在这里把 straight 和 elpacca 放在一起比较其实并不是很合适。
当然 straight 也有自己的实现很 tricky 的地方，straight 的所有包都必须得是一个 git 仓库，即使是在 ELPA 上 host 的没有 git 仓库的包也是如此。因此 straight 处理 elpa 包的机制是自己写了一个 CI 自动从 ELPA 同步包并且生成 git 并把这些生成的 git 仓库 host 在 github。以前我有遇到过 CI 遇到问题导致这些生成的 git 仓库更新不及时，然后有的包恰好需要这些更新不及时的包的最新版，导致安装出现问题。不过这套 CI 总体而言还是稳定的，上述问题我也就遇到过一次。
1 个赞