我用的doom-emacs on macOS. 刚打开Emacs的时候还是很顺滑的。但是过了一段时间，开多了几个buffer，尤其是打开多个项目（folders with .git at root）之后就渐渐出现延迟。开始我还没在意到，是偶尔有一次用vs code打开项目，我直接就被轰飞了。编辑TypeScript code是可以这么顺滑的吗？
在Emacs里关掉行号显示有一点帮助。但是相比起来vs code真的是快太多了。导致我现在可能有一半时间在用vs code写代码。大家有同感吗？解决方案？
把js2-mode 换成js-mode 你会发现速度嘎嘎的
因为各种模式偶尔莫名的卡顿，我把doom emacs 换掉了。
V8 高效的垃圾回收机制依靠的是 多线程并行标记和清理.
emacs 的卡顿很多时候归咎于 落后的 GC , 这也是我最不满意的一点. 任何情况下, 只要 gc 达到了那个临界值, 就阻塞回收, 你不得不等它回收完毕.
这时候, 你只有两种选择方案:
当然, 最有效的一个优化途径是 利用 idle-time 不断地触发 GC, 这个就是 插件 gcmh 干的事情.
gcmh + 方案2 , 是一个 emacs 很常用的优化方案. doom-emacs 就是这么做的. 但是有时候还是无法令人满意, 比如编程的时候, 所以, 我现在编程大部分在vscode, emacs org+roam 用来做笔记, vim 用来在终端临时查看一些文件.
lsp-mode 默认开启的东西太多，舍弃一些功能之后可以做到不卡顿，单 lsp-enable-* 我就关了 9 个。 论坛内有很多人分享过如何优化，值得借鉴，例如陈斌这篇
但终究不能像 vscode 那样既流畅又功能丰富，所以习惯的话直接用 vscode 写代码吧，没有任何问题。
我做专业前端程序员已10年了，一直用的Emacs，每天就是和javascript/typescript打交道。Emacs是我用过的所有编辑器和IDE中性能最优秀的。我对VSCode也有专门研究。事实上，我一年前发布的教程“如何提高编程速度”里一半的内容是在教VSCode的。从来也没发现VSCode性能可以和Emacs相比。
你可以参考我的配置， GitHub - redguardtoo/emacs.d: Fast and robust Emacs setup. 我主要是基于ctags（目前用universal-ctags）开发，
counsel-etags做代码导航
company-ctags做代码自动完成
html用web-mode，
ts用typescript-mode，js用js2-mode
性能的一个瓶颈可能是自动语法检查，我不用flycheck或者flymake，用我自己的lazyflymake来检查ts，如果是js就直接用js2-mode自带语法检查。
还有一个问题是拼写检查，我用自己开发的wucuo，基于flyspell的API。但性能好很多。
lsp-mode我试用过几个月。我用的lsp server是sourcegraph开发的GitHub - sourcegraph/javascript-typescript-langserver: JavaScript and TypeScript code intelligence through the Language Server Protocol 他们的产品需要你手动在项目根目录生成jsconfig.json来列出不需要扫描的目录。其他没什么大问题。
stackoverflow了，等我有空慢慢消化。多谢高人指点。
或者还有一种方式，如果楼主习惯spacemacs的按键的话（其实大部分就是vim的按键），可以在vscode下尝试一下VSpaceCode，基本上把spacemacs常用的按键绑定都移植到vscode上了。好像也支持hybrid（就是在insert mode下支持emacs按键，我有一段时间不用了，记不太清），让你开箱即用，不折腾。
主力写web用vscode比较好，各种乱七八糟需要靠人力填的细枝末节都帮你处理好了，比如html里写js也有lsp补全（流利程度类似用emacs写elisp），支持优先度就不一样。
emacs性能确实挺一般的（我假设你没用gccemacs），但这里可能是doom的问题（这几天看见吐槽卡顿的贴也不少）
用过lsp mode一段时间，卡得无法忍受，最后还是回到了tide，挺满意的
得看最后是不是默认编译选项…
多半不是
使用gccemacs 配合tabnine 如果 tabnine 不提示M-/ 手动 company-other-backend 速度嘎嘎的, 提示很跟手 , 我是说lsp-ui 基本全开的情况下很跟手 , 我用的是centaur-emacs
额，我打算用您的配置来改进我的Emacs，可是以后我该怎么添加我的一些功能啊
不知道从哪下手啊
我前面把我用的前端开发关键插件都列出来了。
拼写检查不用也没关系。
可以把flymake-mode和flycheck都关掉。语法检查完全可以直接调用命令行，在git的pre-commit-hook完成。
flycheck我一直在用，感觉还好，不卡，还是说大佬的 自动语法检查 指的是检查整个项目的文件，而不只是单个文件，所以可能是 性能的一个瓶颈
我用基于flymake的方案，性能还可以。语法检查都是标准配置，检查单个文件。
调用第三方命令行程序不会是瓶颈，命令行程序返回过多需要Lisp处理的信息是瓶颈。我没有怎么用过flycheck。只不过对于这种需要高频处理命令行返回信息的插件有警惕性。
具体到ts/js开发，专业前端开发工具很成熟了。语法错误都会在浏览器页面和调试工具第一时间报告。后端用js开发的话js2-mode也会自动检查语法错误。所以eslint主要作用就是检查语法风格了。
语法风格从“提高编程速度”的角度分析完全没有必要实时报告。比如我喜欢用单引号包含字符串但是团队要求用双引号。当我写代码时按自己风格随性写下去是效率最高的。
commit时在pre-commit hook可以调用eslint把这些琐碎的风格问题都扫描出来。修正这些问题也很简单，可以用eslint --fix一次修正。甚至修正也可以完全自动化。放在emacs的after-save-hook里或者git的pre-commit hook都可以。
如果采用以上工作流，ts/js开发不需要flymake或者flycheck。
仅就前端开发来说，vscode的默认设置是非常低效的。它调用eslint把严重的语法错误和简单的语法风格问题一股脑地列出来。需要你把控制焦点移到高亮的问题所在，按C-.或者CMD-.来修正单个问题。
我在 ~/.doom.d/config.el 添加了这句，否则经常卡死几十秒：
(use-package! lsp-mode
:config
(setq lsp-enable-file-watchers nil)) ; https://emacs-lsp.github.io/lsp-mode/page/performance/#ignore-watch-foldersfiles我个人经验vs code确实是做的太多。有的时候甚至不让我保存文件，因为保存前的一些处理线程可能有延迟甚至卡死了，右下方会有弹出提示正在…。
微软必须照顾普通用户，用户误操作搞出大新闻麻烦了。可以调整默认UI或安装一些小众插件（https://marketplace.visualstudio.com/items?itemName=emeraldwalk.RunOnSave&ssr=false#review-details） 实现类似Emacs的工作流。不过花额外的精力把VSCode变成Emacs对我好像是多此一举。