有没有人觉得JavaScript/TypeScript (LSP)开发很卡啊?

我用的doom-emacs on macOS. 刚打开Emacs的时候还是很顺滑的。但是过了一段时间,开多了几个buffer,尤其是打开多个项目(folders with .git at root)之后就渐渐出现延迟。开始我还没在意到,是偶尔有一次用vs code打开项目,我直接就被轰飞了。编辑TypeScript code是可以这么顺滑的吗?

在Emacs里关掉行号显示有一点帮助。但是相比起来vs code真的是快太多了。导致我现在可能有一半时间在用vs code写代码。大家有同感吗?解决方案?

2 个赞

把js2-mode 换成js-mode 你会发现速度嘎嘎的

因为各种模式偶尔莫名的卡顿,我把doom emacs 换掉了。

V8 高效的垃圾回收机制依靠的是 多线程并行标记和清理.

emacs 的卡顿很多时候归咎于 落后的 GC , 这也是我最不满意的一点. 任何情况下, 只要 gc 达到了那个临界值, 就阻塞回收, 你不得不等它回收完毕.

这时候, 你只有两种选择方案:

  1. 将临界值调的足够大, 忍受将来长时间的垃圾回收
  2. 将临界值调的足够小, 忍受回收时间短但足够频繁的垃圾回收.

当然, 最有效的一个优化途径是 利用 idle-time 不断地触发 GC, 这个就是 插件 gcmh 干的事情.

gcmh + 方案2 , 是一个 emacs 很常用的优化方案. doom-emacs 就是这么做的. 但是有时候还是无法令人满意, 比如编程的时候, 所以, 我现在编程大部分在vscode, emacs org+roam 用来做笔记, vim 用来在终端临时查看一些文件.

3 个赞

lsp-mode 默认开启的东西太多,舍弃一些功能之后可以做到不卡顿,单 lsp-enable-* 我就关了 9 个。 论坛内有很多人分享过如何优化,值得借鉴,例如陈斌这篇

但终究不能像 vscode 那样既流畅又功能丰富,所以习惯的话直接用 vscode 写代码吧,没有任何问题。

1 个赞

我做专业前端程序员已10年了,一直用的Emacs,每天就是和javascript/typescript打交道。Emacs是我用过的所有编辑器和IDE中性能最优秀的。我对VSCode也有专门研究。事实上,我一年前发布的教程“如何提高编程速度”里一半的内容是在教VSCode的。从来也没发现VSCode性能可以和Emacs相比。

你可以参考我的配置, https://github.com/redguardtoo/emacs.d 我主要是基于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开发的https://github.com/sourcegraph/javascript-typescript-langserver 他们的产品需要你手动在项目根目录生成jsconfig.json来列出不需要扫描的目录。其他没什么大问题。

8 个赞

:hushed: stackoverflow了,等我有空慢慢消化。多谢高人指点。:pray:

或者还有一种方式,如果楼主习惯spacemacs的按键的话(其实大部分就是vim的按键),可以在vscode下尝试一下VSpaceCode,基本上把spacemacs常用的按键绑定都移植到vscode上了。好像也支持hybrid(就是在insert mode下支持emacs按键,我有一段时间不用了,记不太清),让你开箱即用,不折腾。

1 个赞

主力写web用vscode比较好,各种乱七八糟需要靠人力填的细枝末节都帮你处理好了,比如html里写js也有lsp补全(流利程度类似用emacs写elisp),支持优先度就不一样。

emacs性能确实挺一般的(我假设你没用gccemacs),但这里可能是doom的问题(这几天看见吐槽卡顿的贴也不少)

有冲动尝试gccemacs, 但是看起来还是很折腾。不知道这个native compilation是不是一个福音。如果正式release的话是不是意味着emacs 约等于 gccemacs了?

用过lsp mode一段时间,卡得无法忍受,最后还是回到了tide,挺满意的

得看最后是不是默认编译选项…

多半不是

使用gccemacs 配合tabnine 如果 tabnine 不提示M-/ 手动 company-other-backend 速度嘎嘎的, 提示很跟手 , 我是说lsp-ui 基本全开的情况下很跟手 , 我用的是centaur-emacs

1 个赞

额,我打算用您的配置来改进我的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-.来修正单个问题。

2 个赞

我在 ~/.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对我好像是多此一举。

1 个赞