我基本上只用rg关键字全库检索+denote文件名过滤 
完了，用惯了doom管理package，有点忘记怎么自己安装package了😂
您这样相当于维护了自己的elpa，避免受到主elpa滚动更新的影响么？
另外，传统的package.el不支持的github上的包，您是手动安装么？
@rlry @Jousimies 感谢二位，你们的方案都是以文件作为粒度，但是我是大文件里有很多heading，所以我需要以heading为粒度的全文搜索，那就还是只有helm-org-rifle了😂
我一般不用github上的包，不得不用的话直接用源代码算配置的一部分。
没用过 rifle 或者 helm. 貌似的本质就是搜 heading? 我用 ivy 也可以搜 heading, 但是搜索用的命令是从 scimax 里抄的, 名字叫 ivy-org-jump-to-heading-in-directory. 写法很简单, 你用 vertico 应该也可以改成你要的. 话说 minad’s stack 中真的没有搜 heading 的命令吗? 那还真是挺令人意外的, 从 ivy-org-jump-to-heading-in-directory 来看, 这功能挺容易写的
consult-org-heading 可以直接搜 headings 的。
1 个赞
我的配置保险是一份稳定的, 很少升级的 .emacs.d. 可以理解为与主配置有很大同步延迟的同等配置. 我用 org 文学编程管理配置, 升级任何配置只需要 tangle 一下. 主配置挂了的时候我只需要 emacs --init-directory 选备用配置文件家就行了. 不知道这个方案能不能适用于 doom
自从之前有一次升级以后不能用，影响工作，早就切掉了，又不在乎启动速度远程机器一直挂着，不会关闭，本地也就一天开一次，无所谓快慢，自己需要啥插件自己加，很方便
doom 3.0有什么重大更新吗？
doom 在 lazyloading 上面做了很多的努力。但是 doom 本身的框架复杂度是很高的，这也影响到了 doom 的启动速度。
所以自己写的的配置，如果借鉴了 doom 的 lazyloading 的思路，但是不需要它的框架包装。是可以做到比 doom 启动速度更快的。
我以前使用 doom 的时候，emacs 启动速度大概是 0.6-0.9s 启动速度之间。换成了自己的配置后，启动速度是 0.25s。这还是因为我没有 lazy-load evil 的情况下 （evil 相对不太容易 lazy-load，而且 lazyload 的意义不大）。如果我的配置移除 evil，启动速度是 0.15s。
总结：lazy-load 其实没有很复杂，也没必要神话 doom 的魔法。自己写自己的配置减少了框架复杂度，在启动速度上完全可以超越 doom。
spacemacs,doom都用过1年左右，spacemacs在windows上是慢，doom速度可以，两者的问题都是升级时痛苦。会因为各种问题出错挂掉，极端时花几天时间排查，非常痛苦。
两年前实在忍不了，花了一周多时间，以 centaur emacs 为基础，将全部配置移植。包管理采用 borg，整个.emacs.d目录git管理起来，所有包作为submodule，个人配置也作为一个包，也是一个submodule。从此再没有升级焦虑，并且包和配置可各自变化，离线机器之间可通过git patch升级。
2 个赞
Emacs最好包管理： Git + Package submodule.
重大变化：将 core 剥离单独维护。使用straight → elpaca. 不依赖use-package…
我觉得这样解耦会比较好，也能降低维护成本，就是不知道什么时候会发布。
本人也在用这个好久了:
非常感谢你的包.
配合 git rev 锁定版本, 随时都可下载适合当初的 Emacs 版本的包:
(customize-set-variable
'package-archives '(("elpa-local" . "~/.emacs.d/.local/elpa-local/")
("melpa" . "https://raw.githubusercontent.com/d12frosted/elpa-mirror/dcdc8450175bc1cdad5ef70325b93ae2d5dc70a3/melpa/");; 2025-02-24 18:50
("gnu" . "https://raw.githubusercontent.com/d12frosted/elpa-mirror/dcdc8450175bc1cdad5ef70325b93ae2d5dc70a3/gnu/");; 2025-02-24 18:50
("org" . "https://raw.githubusercontent.com/d12frosted/elpa-mirror/dcdc8450175bc1cdad5ef70325b93ae2d5dc70a3/org/");; 2025-02-24 18:50
("nongnu" . "https://raw.githubusercontent.com/d12frosted/elpa-mirror/dcdc8450175bc1cdad5ef70325b93ae2d5dc70a3/nongnu/");; 2025-02-24 18:50
))
1 个赞
我是通过 Borg 使用 Git的 submodule 从包的仓库直接安装包，每周滚动更新，很稳定。即使出现问题也可以随时回滚到之前的版本。
可以参考 Borg 的例子配置，
也可以自己从头创建项目。
其实这个问题很好解决，只要以项目的角度看待你的doom配置就行了，doom不断的更新，和其他package更新都会导致emacs break。加个CI就行了，每次push都给编译一下，有什么问题马上就知道。
以下是我的CI配置，每次push都会编译doom，每次tag都会打包整个.emacs.d并发布(也解决了配置备份的问题)。如果有private submodules，需要设置一下GH_PAT。
.github/ci.yml
name: Doom Development Build
on:
push:
branches:
- master
paths-ignore:
- README.md
tags:
- "v*.*.*"
pull_request:
paths-ignore:
- README.md
jobs:
emacs:
runs-on: ubuntu-latest
steps:
- name: Checkout .doom.d repo
uses: actions/checkout@v3
with:
path: .doom.d
token: ${{ secrets.GH_PAT }} # `GH_PAT` is a secret that contains your PAT
submodules: recursive
- name: Checkout doom emacs repo
uses: actions/checkout@v3
with:
repository: doomemacs/doomemacs
path: .emacs.d
- name: Install emacs
run: |
sudo add-apt-repository ppa:ubuntuhandbook1/emacs
sudo apt update
sudo apt install emacs emacs-common
- name: Build doom emacs
run: |
export DOOMDIR=${{ github.workspace }}/.doom.d
.emacs.d/bin/doom sync
# TODO
# - name: Test Emacs
- name: Package
run: |
PLATFORM="ubuntu_emacs29"
tar zcvf emacs.d_${PLATFORM}.tar.gz .emacs.d/
sha256sum *.tar.gz > "emacs.d_$PLATFORM.txt"
echo "release_file=emacs.d_$PLATFORM.tar.gz" >> $GITHUB_ENV
echo "checksum_file=emacs.d_$PLATFORM.txt" >> $GITHUB_ENV
cat $GITHUB_ENV
du -ch emacs.d_$PLATFORM.tar.gz
- name: Upload binary file and checksum file to Release
uses: softprops/action-gh-release@v1
if: github.event_name == 'push' && contains(github.ref, 'refs/tags/')
with:
draft: true
files: |
${{ env.release_file }}
${{ env.checksum_file }}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
感谢大家热情反馈！等我周末仔细研究一下！
我理解最终的运行效果取决于下图的代码部分：
由于Emacs升级频率相对较低，且代码相对稳定，暂且忽略不谈，因此配置的稳定性主要取决于：
- 三方包如何管理
- 是否使用三方配置
- 个人配置的管理
我理解一是从源头上减少不稳定因素，例如不使用三方配置。 二是尽快地暴露可能问题，例如使用手动包管理而非自动包管理
我再学习一下CI， @DR_MING 这个思路就是尽快地暴露可能问题么？
不过我的问题是，有时候doom升级出错了之后，回滚也会出错，这时候就要从头install，有些麻烦…… 这时候经常是上游仓库也出错了么？
最近需要先快速地配置环境，而且我的三方包比较多（不稳定性的来源😂），因此还是先用自动安装的方式，这样依赖装起来比较快。
我看了您之前的文章，我准备有时间的时候从现在的方式迁移到您说的手动包管理： Git + Package submodule.
不过我有一个问题：
包之间的依赖您是纯手动管理，还是有什么可视化展示包之间的依赖关系的工具，就像brew deps一样？
这时候不得不跟楼主推荐下 Centaur Emacs了 
1 个赞