断断续续几个月吧. 我当时应该是先把自己最需要的功能挪过来 (写C++, vim 键位), 这样几个小时就有一个能用的配置了. 后面边用边看有那些比较想要的功能一点一点加.
2 个赞
五年前的thinkpad，doom 启动 1.9s ，自己的配置在 1.8~2.1s之间。
比spacemacs快，跟doom差不多
裸的emacs也就很难达到吧
emacs的启动速度，比neovim差了不少
doom 的 breaking change 很多，而且也有时不时更新后发现新 bug 经常更新以后就爆一个大问题，而且 500 多个 issue 越攒越多了。我是不知道这种配置文件要怎么写测试文件来测试更新后会不会有 bug。
spacemacs 应该是已经过了那个临界点了，现在维护性已经极大下降了。不知道 doom 什么时候过这个临界点。
那我自己的配置和裸 emacs 一样快，相当于一开始就编译进去了
这是怎么做的？
byte-compile + dump emacs + lazy load 呗。我不用 Spacemacs 就是因为它不能 byte-compile 配置。
最好是用emacsclient，开机了就不关。
而且nvim是tui程序，可以在term或者vterm里用，哈哈。
用了4天时间，总算把 vertico evil company 之类的“基础设施”的东西迁移出来了。现在已经开始不用 doom 而是用我自己的配置开始继续写新的配置了。下一步优先配置 org 和 magit，然后再其他的慢慢来。
我看doom的配置文件，开头的注释都是
;; -*- no-byte-compile: t; -*-
这是关掉了byte-compile?
只是单一文件的声明：不要把我（本文件） byte-compile 了。
维护自己的配置其实很简单的，代码简单直白，因为你自己的需求自己知道，自己不需要的也不写，你不需要和架构做斗争。。。。
3 个赞
这段时间抄配置所以大量的看了 doom 的配置代码。doom 的配置里的 advice 的数量真的是惊人。。。doom 4万多行的代码里可能大部分全部都是这些 advice 充满了。我很好奇充斥如此之多的 advice 是要怎么维护的过来。。。
我的配置历程是这样的。从 doom -》radian-》自攒配置-》doom。
-
从公开配置到自攒的理由：
想一切尽在自己掌握，知其然知其所以然。 -
从自攒到doom的理由：
emacs生态太庞大，插件多，更新快。有些配置自己搞起来太费时费力。 可以利用doom社区的力量，大家一起攒，而且doom的模块化和性能都比较优秀。 省时省力。所以，以后打算主力doom，自己维护一个轻量化最小配置以备紧急救援使用。
1 个赞
不是自己的配置终究不是自己的，想要加东西改东西都不够 straightforward
还有一种方法是熟悉 doom 的 codebase，把 doom 变成自己的项目（
doom 的代码其实注释写的很好，把它的那些封装代码剥掉（其实并不困难），抄配置其实并不麻烦😂 doom 的配置其实就是里面充斥了无数的 advice 的配置，真的是历年来无数人 bug report 反馈出来的血和泪攒出来的各种奇怪的 hack。。。当然这些 advice 肯定会不乏过期的 upstream 已经修复的就是了。
但是 advice 这东西肯定不能乱抄吧。。。反正如果一个 advice 我没理解在做啥，以及我没理解为啥要这么 hack，我肯定是不会抄的。
doom 主要的问题还是在于基础设施搭的框架，以及 cli 上，如果作为个人自用的配置，完全没必要向他那样搞那么复杂。经常更新一下带来一个 breaking change。。。以及就是无数的 advice 互相耦合在一起，导致 debug 极其困难。
1 个赞