自子龙山人的优秀教程进入emacs的世界, 一路使用和阅读过很多优秀的emacs配置，spaceman’s、doom emacs、centaur emacs、lazycat-emacs、 redguardtoo emacs、Daviwil emacs等，每次都像是进入了一个新世界。
随着对emacs越发地理解和熟悉，我发现想使emacs配合自己的工作达到如臂指使的地步，就一定要深入了解自己的配置结构。不仅仅是这些代码配置了什么这种事情，而是清楚地掌握这些代码的低抽象层级和调用流程。
因此在从上述优秀代码吸取了大量知识的基础上，出现了我自己的emacs 配置，也是我的工作和生活解决方案：
nowisemacs，希望能对也尝试自己攥配置的同学有一些帮助。
nowisemacs试图解决我遇到的这几个问题：
- 代码抽象程度太高，一旦遇到问题不知道如何排查和解决
- 现有的feature不能满足需要，经常想要拓展新的功能，但一改又影响了别的地方
- 装了大量同类型的包却有些混乱，甚至难以熟悉
- hack太多则难以后续维护，hack太少却又不知道怎么去满足需求，换而言之，难以控制默认配置的复杂度
- 代码洁癖，不想看到自己不用的代码或者包，但因为缺乏对整体的把控，删除后影响正常使用。
我想先给出我度过这几个初学者困难的思路历程：
- 在一些成熟的通用性配置doom emacs等使用了很长时间，这段时间我主要熟悉了emacs的各种或酷炫或实用的功能，这极大地引起了兴趣并且明确了一份优秀的emacs应该是什么样的
- 尝试自己写配置，但很快因为不知道如何梳理自己的配置流程被阻塞
- 找了一份非常native 的配置，lazycat-emacs，学习如何用最底层的方法配置所有的代码，包括手动管理包，手动控制加载顺序等
- 理解了emacs在启动后需要哪些东西之后。我需要搞清楚的事情变成了两个：第一，实现这些功能，第二，控制配置的抽象等级以不提高维护压力
nowisemacs的配置并不是一下子就有的。有一篇文章《从操作系统架构的角度理解emacs》给了我很好的启发，让我尝试从一个emacs本身而不是emacs用户的角度去使用emacs。作为一个emacs，我该如何满足用户需求呢？
第一，当用户给我需求的时候，我需要知道怎么组合现有的功能去实现这个需求；第二，我能找到或者实现这些功能。
有了这个思路，nowisemacs尝试分离功能结构和代码结构来解决这个问题：
- 代码结构。nowisemacs也采用了平铺式的代码结构，也就是尽可能不使用包的嵌套或者跳跃配置，包的加载顺序是顺序执行的。这种方法最大的优点就是容易排错和维护。但平铺结构的一大问题就是难以对代码进行不同需求等级的把控，容易存在明明有一些功能却找不到。
- 功能结构。这里是为平铺带来高角度的视角。nowisemacs会优先复用emacs自带的包或者功能，这些代码往往功能单一性强且实现简洁，彼此之间配合起来浑然天成。在这个基础上，nowisemacs 采用org mode大纲式管理所有的功能需求，结构是从代码出发的，但却以功能为层层分类，这样有需求时可以迅速找到可用的功能。
- 代码抽象层级。nowisemacs尝试保证看到任何一行配置代码时，都和基础代码一样清晰。因此放弃了容易管理但底层难以理解的use-package，经过一段时间使用也放弃了代码清晰但管理较为重复的手动配置，最终使用了setup这个包。setup的主要缺点是功能较少，但极易的拓展性和随时可以expand成“基础配置”的高可读性是其成为了理想选择。
- 包复杂性控制。在选择包时会尽量选择依赖少的、实现思路简洁的、需要用户配置尽可能少的包，这样的包意味着配置简单且耦合性低，完全可以作为某个子领域的独立解决方案，甚至无需配置快捷键，仅通过M-x在需要的时候搜索相关函数即可。这也意味着nowisemacs的选择是激进的，即不存在向后兼容，代码和包若用途较小则会被去除。
其实我的配置没有太多值得称赞的地方，我想和大家分享的是我的配置思考和沉淀下来的理念，希望能给其他曾经和我一样望着emacs代码高山却不知道如何迈步的用户一点借鉴的意义。nowisemacs是我尝试这种方式的一个实现，欢迎尝试里面的配置或者提issue～～
其实真的蛮感谢emacs china的各位和其他喜欢emacs乐于帮助的人，为新人熟悉和理解emacs起到了至关重要的作用，是领路人和引导者。对我个人而言，我受到了很多帮助和启发，这甚至改变了我的科研、工作和生活的主要方式。
40 个赞
实时语法检查/纠正 lsp-ltex 或者 eglot-ltex
language tool 是一个支持20多种语言的免费语法检查软件。作为lsp的language tool emacs客户端，这两个包相比之前我用的emacs-langtool等有着如下优点：
- 非阻塞性，实时检查不卡顿。
- 以各种标记提示用户哪些地方的单词或者书写存在问题，并支持多种方法查看建议和一键修改。
如图一个简单实例，eglot提示noo存在问题，鼠标悬停发现是：possible spell error，单击后提示了几种解决方案，选择no后自动完成了纠正。
ltex还支持侧边栏查看所有错误等功能，对于英文写作是非常有用的
3 个赞
popper，统一管理各种临时的emacs弹出窗口
Emacs 的各种窗口弹出非常恼人，经常出现临时查看一些东西，关闭却破坏了先前的窗口结构。Popper通过多种方式统一设置指定mode/buffer，并控制弹出方式，确保这些窗口在使用后会无痕消失，不破坏结构。
进一步的，还只是一键弹出先前临时窗口和遍历历史临时窗口的功能。用起来真的爱不释手
1 个赞
Nasy
5
好奇，如果 setup 内的代码有错误，setup 是会 ignore，warning，还是抛出错误，阻止加载啊？
dtache 方便的分离和管理 shell 命令
这个包在elpa里，通过dtach来实现类似于screen的一些功能。主页分享了详细的说明文档和youtube的演示链接。
主要实用的地方如下：
- detach。emacs进程被kill了也能继续运行，以后还可以连接过来，特别适合不稳定的远程连接等
- 管理这些命令。已经运行的命令可以很方便地拿到运行过程/结果的buffer，可以随意选择随意浏览，随意重新运行等等，因为这些buffer都是文本信息，因此detach还支持diff和copy等操作。
- 如果你和我一样是embark的用户，很灵活的可以选择和更改操作。detach对embark的支持很好
- detach提供了大量和用户执行命令相关的元数据，包括时间、运行状态等，还可以把这个session存储为文件以永久化。
在我个人的使用经验中，dtache特别适合对需要较长时间运行的命令进行管理和整合，方便的多次运行和详细的控制信息是我可以放心的进行各种操作。
setup的代码就是一堆宏，换句话讲。setup在emacs启动并运行这些代码的时候就消失了，emacs看到的是原生的配置信息。我举个例子：
我们配置一个package的时候可以进行结构化的配置，这是我们写下来的有层次的代码,
(setup diredfl
(:hook dirvish)
(:autoload test-command)
(:bind "C-c h" test-command)
(:with-map dired-mode-map
(:bind "TAB" dired-subtree-cycle)))
当运行时，宏会首先被展开成下面的代码：
(progn
(add-hook 'diredfl-mode-hook #'dirvish)
(progn
(autoload 'test-command "diredfl" nil t))
(eval-after-load 'diredfl
#'(lambda nil
(define-key diredfl-mode-map "h" #'test-command)))
(eval-after-load 'diredfl
#'(lambda nil
(define-key dired-mode-map " " #'dired-subtree-cycle))))
接着emacs才会执行这些代码。
因此，如果错误来源于这个宏的不对，那么emacs会直接报出宏展开的错误，如果是包的配置不对，才会报出功能性的error。这两者均会直接中断运行。
但如果这个宏包含了异常处理，那么就会进行处理后正确运行。（也就是说，用了setup配置，和直接手动配置没什么运行上的区别，都是用户写了什么样的流程就怎么做，没有复杂的机制或者黑盒子）错误处理不是来源于setup，而是用户
Nasy
8
我知道是宏…我想要的只是当我这个区块的配置出问题时，不影响其他配置加载
看起来没有leaf的这个功能…（
哦哦，我理解你的意思了，你提出的是一种类似于try except的代码。setup默认只有很简单的一些宏，这种很实用的额外功能只能用户自己写，它确实没有这种处理办法。感觉我可以去leaf那边看能不能把这个保护机制搞过来，加在一些容易出问题的配置上。感谢你的信息 
1 个赞
我的使用经验：
- 自己编写插件，代码需要高度抽象和简洁，为了避免重复代码需要编写一下简单的 macro
- 配置代码最主要的目标有三个：扁平化易维护、启动插件尽量少、按键触发新插件加载
- 没事别更新，用Git Submodule控制住最稳定的插件版本组合，能工作就别天天更新，稳定环境干活最重要
相对于上面我的经验，我在社区看到的一些比较有趣的现象：
- 对外分享的插件代码写的不够干净，代码量大了以后自己维护都很困难
- 配置代码过度封装，出了问题不容易调试，当需要对一些插件进行高级微调，反而受限于代码封装和包管理插件的框架限制，配置代码，最朴素的写出来能够理解所有配置的意思就行了，没有必要在配置文件上雕花
- 更新频繁，特别喜欢很多插件一起更新，更新挂了后，每天没时间干活，都在折腾版本升级
大家都习惯搜集一些高级插件，我的使用经验是，不管插件功能再强大，只要使用频率低或者用着心智负担太大的插件果断删除，真正天天用的插件没几个。
29 个赞
LdBeth
12
这个有没有不依赖鼠标的解决方案？我觉得 ivy-flycheck 那样就很好
lsp-ltes不清楚，但eglot-ltes可以不用鼠标，光标移动到单词上会自动弹出一样的提示，执行code-action会在minibuffer🀄️弹出选项，和用鼠标没什么区别
1 个赞
Joxos
16
如果只是恢复窗口布局，winner-mode会不会轻量一点。。？
Joxos
17
看到你用的也是corfu，不知道你在使用clangd作为语言服务器时有没有无法正确补全snippet的情况？
如果是从轻量级的角度，那确实是winner-mode好，毕竟内置了。但如果从管理临时窗口的实用和省心的角度，popper优秀太多。我两者都用，这两者在我看来是不同的目的，popper的作用非常单一化，winner的用途反而更广泛一些，我认为前者是后者在细分领域的强化，因此混用也很方便
很多时候，用户只是想临时查看一下文档，或者打开一些buffer临时看一下，还有可能是运行一些命令待会再看一下。这些操作都可能会多重复几次，比如看了一些buffer内容后发现需要再看一些新的buffer。
起初你在buffer a，b工作工作，然后突然有了临时需求，因为emacs不同mode的窗口弹出十分混乱，有的是在下面临时弹出，有的是复用已经有的buffer，这几种情况只要你稍微多追几次，你原来的工作布局就会全乱掉，buffer a和b甚至都不在你的可视区域了，既不能作为阅读的参考，想回去的时候只能一路winner undo。但这些临时buffer会打乱winner的线性历史，有时回不去了。
popper会把所有的这些临时buffer统一管理，比如在下方开一个临时窗口，所有的buffer都会在这个窗口里，确保不会影响到任何之前的buffer，还可以很方便的遍历历史和随时弹出先前的内容。
这玩意讲起来有点绕口，其实用一下就知道了。但如果感觉winner已经满足了，那继续用winner就好，没必要增加自己用不到的需求，平白增加维护压力😄。
3 个赞
clangd我用起来好像没啥问题啊，我录了个动态图，你看一下我有没有理解对你的问题，是snippet吗？
持续 buffer 和 临时 buffer 的概念用处挺多的，最著名的就是 which-key 的临时 buffer。
1 个赞
给你点个赞！