我一般是先 fork，然后clone到本地，删掉从melpa安装的包，然后 load 从github clone的包。大家是什么样工作流程？
1 个赞
我用的是同样方法。这么做需要的手动操作比较多，Emacs 也得要重启。
一个小提示是：可以滥用 load-path 的优先级，同时保存 ELPA 和本地的包，比如
(use-package no-littering
:load-path "~/src/no-littering"
:ensure t)
注意这么做 ELPA 提供的 Autoload 依然生效（利弊都有）。我这么做的出发点是避免频繁修改 init.el。
1 个赞
package.el 没法处理这样的需求，打算试试其它的包管理器，比如
1 个赞
我的做法是，写一个单独的最小配置，去掉所有不必要内容。
package 可以从 elpa 安装，或者利用 el-get 从源代码安装。elpa 包跟源代码有时候并不完全是新／旧的区别，比如 org-mode 的 elpa 是 build 之后打的包，而源代码目录结构就比较复杂。
简单的调试写些 hook / advice，如果需要改动源代码的，记得删掉 *elc，然后直接在安装的 package 上改。
我这样做的考虑是：
- 避免修改不当影响主力配置
- 有一个稳定的主力配置可用来修改测试配置
- 无需重启主力配置以验证修改结果
通常我连调试的步骤都代码化，这样以后每次需要验证修改结果的时候，只需：
$ /path/to/emacs -nw -Q -l /path/to/test.el
结果直接呈现。
2 个赞
我刚刚迁移到了 straight.el ，可以和 use-package 一起用，基本变化不大，只需要把 :ensure t 改成 :straight t ，然后 package.el 的设置都可以去掉了。但是Emacs的启动速度会慢1-2s。
所有的包都是从 github，emacs-wiki 或者其他托管网站下载的，放在straight/repo里，Emacs 加载的是straight/build目录里的包。每次修改repo里的文件，重启Emacs就会重新build。
这样，我就可以使用自己fork的版本的代码了，随用随改，而且straight还可以指定上游代码，随时可以更新本地代码，非常方便。
1 个赞
我也是用 package.el + use-package 的，看起来很容易迁移到 straight.el，后者的说明很多，我原本还打算看看清楚再迁移的。
是不是所以的包在各自的 Git Repo 中？这样上游应该也必须是 Git Repo？如果是的话，emacs-wiki 是怎么支持的？
我也是用 package.el + use-package 的，看起来很容易迁移到 straight.el，后者的说明很多，我原本还打算看看清楚再迁移的。
一开始我也这么想的，文档太长了，以为又是个很复杂的玩意。我是直接从 Getting started 开始看的，这个例子一目了然。
(use-package el-patch
:straight (el-patch :type git :host github :repo "your-name/el-patch"
:upstream (:host github
:repo "raxod502/el-patch")))
是不是所以的包在各自的 Git Repo 中？这样上游应该也必须是 Git Repo？
repo目录里是源代码，type和host可以指定。如果没有指定，:straight t ，会自动安装对应的包，不清楚内部实现。
如果是的话，emacs-wiki 是怎么支持的？
因为我使用了Emacs wiki 的包，安装是没有报错的。试用 straight.el 之前用过了 quelpa，quelpa 已经宣布放弃支持wiki了，有些包会安装失败。straight.el 没有这个现象，只是安装过程十分缓慢。
不清楚是不是可以编辑，提交emacs-wiki的代码，但是安装应该没问题。
straight 不是只支持 Git 吗（这里提到 GitHub - radian-software/straight.el: 🍀 Next-generation, purely functional package manager for the Emacs hacker. )，例子中为何还要指定 :type git ？
package.el 这么做还是不太方便，package-load-list 不支持解析依赖，比如你只想测试 Helm 的话，得要自己单独装一份到一个新的 ELPA 路径。
这里是 straight.el 的解决方法，看起来要容易些：
本帖的主题不是侧重在调试么，所以配置方面不必太完善，依赖可以手动解决，几十行代码做成模版，也不算麻烦。
独立的配置，避免相互干扰（即影响测试，又影响主力配置），更有利于测试。自动化测试，每次启动 emacs 得到的是一个全新的环境，确保测试结果的一致性，比在主力配置上原地修改／测试更可靠。
新年快乐！
package.el 这么做还是不太方便，package-load-list 不支持解析依赖
之前用package.el，use-package 的 defer t 有时不起作用，不知和这个有没有关系。
这个包传达的理念很先进。除了更方便用户参与贡献代码，它还使得用户把个人配置和第三方的包都作为自定义的对象，比如用户完全可以使用自己的fork，把扩展也变成了用户配置的一部分，只要定期git rebase就可以了。
我觉得这也许会导致 Emacs 的碎片化更严重，Github 使得 Emacs 各个包的开发更统一了，但是用 straight.el 又意味着每个人都可以有某个包的fork。那这就又像Emacs wiki 时代到处是代码的情形了，各种包的不同fork分散在各个用户的Github上。系统总是向熵增的方向演化。
1 个赞
Emacs 本身的设计不鼓励用户直接改代码。
这年头 Git 和 GitHub 太流行了，以至于很多人都在滥用它们，把它当网盘和合作编辑。GitHub 也算是对 Git 的一种滥用了。
我也换到了 straight.el，跟自己手动安装一样，M-x find-function-on-key 能直接跳到 Git 下源代码，任何修改都记录了下来，假如要给上游提补丁的话，应该也很容易。
为了验证 helm-swoop 的这个 pr，试了一下 straight.el，然而这个看似简洁的包管理却十分慢，打开下载文件夹我明白为什么了：
157M ~/.emacs.d/test-helm-swoop-pr124/27.0.50/straight
2.0M |---- /build
155M '---- /repos
416K |- /emacs-async
96M |- /epkgs
77M | |- /.git
| '- ...
30M |- /helm
26M | |- /.git
| '- ...
440K |- /helm-swoop
26M |- /melpa
11M | |- /.git
| '- ...
392K |- /popup-el
1.5M '- /straight.el
由于不支持 shallow clone，每个 repo 都巨大无比，还好测的不是 org-mode。而 el-get 的情况要好很多：
21M ~/.emacs.d/test-helm-swoop-pr124/27.0.50/el-get
13M |-- /el-get
5.8M | |-- /.git
188K | |-- /logo
132K | |-- /methods
6.6M | |-- /recipes
312K | '-- /test
224K |-- /emacs-async
7.0M |-- /helm
2.5M | |- /.git
| '- ...
208K '-- /helm-swoop
配置是一样的：
-
straight
(straight-use-package '(helm-swoop :type git :host github :repo "jguenther/helm-swoop" :branch "fix-helm-display-function")) -
el-get
(el-get-bundle helm-swoop :type git :url "https://github.com/jguenther/helm-swoop" :branch "fix-helm-display-function")
没用过 el-get，是不是用户设置 :branch 的时候就不启用 Shadow clone？因为不然就选不了分支了。
作者还在犹豫吧，没有确定最终方案 Add option for shallow clones · Issue #2 · radian-software/straight.el · GitHub
确实如果指定了克隆的深度，有可能找不到 branch，但是这里刚好是最后一个 commit。
如果不是最后一个 commit，不知道 straight 是不是有其它方法，因为 github 不支持克隆指定的 commit，但是允许下载指定 commit 的压缩包。我安装 org-mode 就是 el-get 下载的 zip，比克隆仓库快非常多。