如何对正在使用的elisp包进行编写调试?

我一般是先 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 个赞

@xuchunyang @twlz0ne

我刚刚迁移到了 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

以后可能会增加其他的支持,更多的文档内容我没去看了,确实有点啰嗦,写个tl;dr放到最上面多好。

通过 Emacsmirror · GitHub 实现的,这里一个个 wiki 文件都被镜像成了 Git Repo

没错

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,比克隆仓库快非常多。