我已经在Centaur Emacs 中用popper 替换了shackle，并做了一些优化，使用起来更方便。给popper提交的PR昨天也merge了。
1 个赞
配置得细腻贴心，很多情况都考虑到了，回头抄一波思路哈哈
花了一晚上时间，我也转了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没有这个，我后面还是加上去吧，这样旧版本也能用
你当前更新一下应该就能用了。
不过which-key的作者说自己不再单独更新了，而是仅在emacs的内置里更新which-key，如果我们如果单独安装which-key的话就使用不到最新的版本了。我打算改成单独安装which-key，等30正式release，再通过version判断的方式移除单独安装的which-key，最新功能和兼容性往往只能做一个取舍。
好的 还在体验中 玩起来感觉还是可以的 配置还没仔细看 麻烦问下 项目管理和搜索用的什么包 keypad模式下没有看到相关快捷键
不过我更常用的还是consult-grep,这个你在normal或者motion模式下按 space s d就能看到这个，使用非常高频，会先提示搜索路径接着开始搜索
另外我有一点个人的使用心得，就是尽可能早地开始自己搭配置。我自己emacs用了很久，刚开始一直是用别人的配置进步很慢，出错不知道怎么debug，加功能也是磕磕绊绊的，直到开始自己做配置才真正有所进步。
因此如果我是给刚学emacs的自己做建议：
- 先多看看别人的配置玩一玩，知道有啥功能，然后尽早自己从头搭一个配置，刚开始不知道怎么配就配个最简单的（我就是这样，而且现在也很简单），坚持先慢慢用起来（可以开一个成熟的配置和一个自己的配置，没事就用用自己的），目的是为了熟悉 emacs 本身的逻辑
- 然后想加什么功能就去尝试查，可以看看blog或者别人的配置，也可以直接问其他配置的作者，一点一点自己搭起来一个
不仅自己进步快，更能真正体会到 “如臂使指” 地使用emacs的感觉，其他人的配置不管再好，也很难给你这个感觉的
感谢建议 我也用了2年了 一直在用别人而配置 太过复杂不好掌握 试了试你的 还不错 也许可以成为一个新的起点 建议 github 开启discussions 有问题也方便大家问
比如常见的一些操作
- 查找文本批量替换 (身为vim患者 还没玩明白)
- 快速回到光标上一次移动前的位置
- 翻页什么的
因为习惯了leadkey的模式 (doom emacs ) 所以起手 都是 空格+project 不常用的命令才会空格+x 去手动执行
关于这个project 其实因人而异 陈斌说编辑器 没有项目的概念 直接打开一个文件 然后就开始编辑 搜索的时候有个rootdir就行 其实我也不用
嗯嗯，已经开了discussion
我之前也是一个vim用户，切换到emacs里发现有些习惯可以很容易保持，比如hjkl或者y p等等，有一些习惯如果想和vim一致就需要使用evil再加一堆包，复杂度变高了导致有时候加功能或者遇到bug时不太好解决。我为了能容易的维护配置和减轻心理负担，大部分我都尽可能用emacs自带的，当然你喜欢也可以加上去，这个只是个取舍而已，
说回操作，这几个功能其实我自己做了替代：
- 替换现在用 M-%(自带的)，或者用meow带的grab指令
- 这个有两个操作可以实现，第一个是比较笨的， 和vim手动记忆位置一样，先按 m+字母比如按 ”m a" 设置一个记忆点，再用 ’ a 返回来，适合于指定返回。另一个是在 nomal模式下先按 g, 再按 m,会看到之前的所有位置，选一个想去的就行
- 翻页的快捷键vim的会和emacs冲突，我就用 C-v 和 M-v 做翻页了，习惯了也还好
用久了特别是功能都是自己加的之后，我反倒越来越喜欢用M-x的方式执行命令了，一是不需要记忆低频功能的快捷键，也不需要额外设置，省心。而高频命令我都设了快捷键，已经肌肉记忆了。二是在输入命令模糊匹配的时候经常看到一些没用过的命令，很有趣或者很有用，是不错的发现。