谢谢推荐，我去看看，我喜欢简洁的方案哈哈
简单的了解下，看起来borg似乎是straight.el或者package.el的替代品？和use-package setup之类的目的不太一样，并不能简化配置管理。不过似乎在包管理上具有许多优势，我比较喜欢基于git的版本管理方案，有空深入用用看
Borg 和 straight还不太一样。但它用的就是git submodule，另处是会将包编译生成elc文件。我的使用来看，仅需要使用setq 进行包的配置，(xxx-mode)开启某个模式，个别使用with-eval-after-load 包裹，不需要使用use-package 对某个包 lazy load等。
Borg assimilate 后，大部份包连 require都不需要。
我现在己经把 use-package, leaf 删除了。
2 个赞
我用了3个月 Borg + use-package，感觉就是通过 Borg assimilate 后的包和内置包的使用差不多了。 用 use-package 也就是为了方便绑定按键，写配置，不用 use-package 确实也可以。
Borg 也有不方便的地方：
- 依赖要自己管理（可以通过 epkg 查看依赖）。
- 对一些依赖外部程序的包（比如 pdf-tools，telega 等），安装起来不方便，需要自己写编译步骤
- magit 在配置项目下使用会变慢（Linux 系统不影响，只会发生在 macOS 和 Windows 上）
我的按键绑定主要用到了meow和one-key,其他按键绑定我用 global-define-key 和 define-key 就搞定。
borg管理，依赖不使用epkg主动查也行，assimilate时会提示你少某个包，那就再assimilate依赖包直到成功，然后再重新build那个包。
依赖外部的包的确是要自己手动，但是好在不是很多。有些通过build-step也可以搞定。
最近出了个rational-emacs，我看它使用emacs自带的版本管理进行配置的版本控制，你或许可以看看。
依赖安装还是查询一下比较稳妥，因为 Borg 是直接从包的 Git 仓库安装，作者的 Makefile 是包含了所有支持的使用方式，有些依赖其实用不到的。不过这种安装方式，会让用户更加了解新安装的包。
回头了解一下 rational-emacs，感谢分享。
1 个赞
你说的不需要的依赖，我用no-byte-compile规避。比如依赖ivy helm的，不用自然就不需要装相应依赖。
LTeX 需要联网吗？还是离线也能用？
看是 offline 了，这样的话不错。
是离线的，我个人也喜欢离线的解决方案，稳定可靠
是的，我也是这样做的。这些操作都是要使用者更加了解使用的包。总的来说，Borg 适合有一定基础的 Emacs 用户，不适合初学者。
配置得细腻贴心，很多情况都考虑到了，回头抄一波思路哈哈
花了一晚上时间，我也转了borg，目前感觉还不错。相比之前我用的straight.el，简单对比一下供感兴趣的大佬参考，首先是优点：
- 可以基于命令行安装和更新，比在emacs里更直观，有一些像doom的用法，但不如doom更新时的信息丰富。不过问题不大，我有一个straight里对比更新commit信息的方法，移出来就好。基于命令行的配置，把大部分工作都放在开启emacs之前（排错，编译等），剩给emacs的任务就只有启动了，清爽。
- 当一些包需要特殊编译方法时，,比straight简单太多，直接在.gitmodules一步一步写上步骤就行。
其次是一些增加的工作量：
- borg会自动添加load-path，处理autoload，并编译.el文件，这样在启动emacs的时候确实方便。但这些工作straight.el也都处理了，没有什么优势。至于对特殊路径例如包的extensions的添加，个人感觉straight.el 的统一放在配置里稍微好一点点。
- straight.el可以设置默认浅克隆，git submodule因为commit的缘故不方便做到depth=1，空间会大一些。
- 我最开始去掉了setup.el，后来又加了回来。borg在这块相比straight.el并没有多做什么工作，我加了setup是为了用之前写的几个比较方便的宏（比如针对没有autoload的文件快捷添加autoload等），也可不用，setup本来就是抽象程度很低的东西。
- borg需要手动处理依赖，有利有弊吧。优点是对包的依赖关系熟悉，知道哪些复杂哪些单一，缺点是卸载的时候比较麻烦，需要看看depend再删，在配置之外还额外维护一份.gitmodules（包含特殊编译，extension路径等）. 而straight.el能够根据配置自动安装或者自动删除依赖。
- 最后一个可能不算缺点。之前用straight.el的时候，我可以分开配置目录和.emacs.d，如下图是我的配置目录，独立于.emacs.d。用的时候init.org会自动tangle出early-init.el和init.el文件到.emacs.d目录，同时一些自动生成的不需要备份的配置也会在.emacs.d中。如果我觉得有问题就直接删除.emacs.d然后重新tangle就好，非常干净。
现在的话因为git submodule的问题，之前的分离配置就比较麻烦了。我把配置也移动到.emacs.d里，因为这里有很多杂文件大部分都不需要备份，我索性写了一个全部ignore然后添加需要的gitignore：
/*
!.gitignore
!.gitmodules
!Makefile
!init.org
!README.org
!etc/
!/lib/
这样本地看起来比较杂乱的配置如下图
每次维护的只有这些了
听起来似乎是抱怨比较多，但其实我对borg还是比较满意的。这种基于submodule方法的最大优点，在我看来是进一步增强了对package的把控细节和把控程度，有助于把握配置和排错。而且我喜欢这种先编译检查再运行的方法。
2 个赞
为什么我觉得 straight 才是最方便的，感觉就一个 straight-use-package，其他啥都不用管。
straight.el确实是最方便的，不管是安装，更新，卸载，额外配置，编译，都是一站式服务。甚至所有的package管理都在配置里，不用维护gitmodules。
我个人是转了borg才体会到straight做了这么多工作哈哈，不过目前用borg也挺爽的，编译和启动分开了，感觉舒服。borg可能最大的优点就是简单，当然，比直接用git submodule多了一些复杂度，我感觉是一种“偷懒，但没有完全偷懒”哈哈
1 个赞
我转 Borg 也有一段时间了，挺好用的。
用了子模块就不要分离了，直接放在 .emacs.d 下面的 lib 文件夹，方便查看和维护。如果出问题了，直接回滚，重新编译（make clean all）
另外，我配置了在开启native-comp 的情况下直接native编译，不需要编译 elc文件。这样在make all 和borg-assimilate 后就不会再去编译一遍eln。缺点是编译的时间，长一点。
在 ~/.emacs.d/lib/borg/config.el 加入下面的配置：
(when (native-comp-available-p)
(setq borg-compile-function #'native-compile))
最近用了 vterm，make 的操作都在 vterm 中执行，不用再切到外部终端。
1 个赞
哈哈，我就是吃了你的安利，谢谢推荐。
borg有提供native的make，但你这个对于native的方法更智能一些。
至于分离配置的问题，其实straight在分不分离配置的回滚都很方便。而我用这种方法的原因是之前用doom的时候，觉得分开配置保证了隔离性，好找好查好搜索，原地grep就行，同时也方便其他人使用我的配置。
“你的vterm配置不错，现在是我的了”
2 个赞
emacs 配置破产了 来试试你的 希望有新的感悟
这个是因为我用了最新的emacs-30，里面自带which-key，就移除了本身的which-key。你这个报错是因为emacs-29没有这个，我后面还是加上去吧，这样旧版本也能用
