lsp服务慢的时候导致的Emacs输入卡顿问题请教

Emacs-general
19

对于lsp server反应慢的情况, 可以把company-idle-delay设置大一点试试, 比如1

20

我不懂前端啊，但是可否试一下把你用的库和工程一起扫描了？ctags 扫描的时候可以添加外部库的路径的。

21

哦哦 :joy::joy::joy:

22

真正用 emacs 写过一次 java，确实非常卡，而且越跑越卡。同样的 lsp java 后端，在 vscode 里顺畅得很，目测还是 lsp-mode 的问题

23

lsp-mode 和 eglot 的补全好像都是基于自带的 CAPF 做的，不知道这个东西有没有类似于 company 的 company-minimum-prefix-length，如果有的话实现你说的这种类似触发应该不是什么难事，只要在输入字符长度满足company-minimum-prefix-length 时请求，删除字符到小于 company-minimum-prefix-length 时取消，多余的其他字符用来过滤即可。体验上应该会有很大的提升，英语好的童鞋可以去 github 上提个 issue，~囧~

24

参考下 GitHub 的这个 Issue

25

fd -g '*.go' | wc -l outputs 33352, 公司用的大仓.

26

根据我的折腾经验，原生编译el, 至少使用27.x支持libjansson, 稍微配置一下 (gc-cons-threshold (* 64 1024 1024)) (read-process-output-max (* 32 1024 1024)) 才会得到一个好一些的体验。个人认为目前编译28.x（支持原生编译），是唯一的效果还行的方法。当然当内存使用超过2～3GB之后难免出现一些问题，有时候需要 M+x lsp-workspace-restart, 实在不济重启Emacs.

以下是lsp-docter (以前是lsp-diagnose)的输出： Checking for Native JSON support: OK Check emacs supports read-process-output-max': OK Check read-process-output-max’ default has been changed from 4k: OK Byte compiled against Native JSON (recompile lsp-mode if failing when Native JSON available): OK `gc-cons-threshold’ increased?: OK Using gccemacs with emacs lisp native compilation (gccemacs): OK

27

我在用scala写大数据的时候也遇到了这种情况，越用越卡，到后来还影响上屏，写scala暂时先用vscode了，golang和python目前还能忍

28

哥，就等你了

29

等我先把 EAF Git Client 弄完， lsp-bridge 的事情估计这半年都没空，公司太忙了。

我主要担心我一旦把 lsp-bridge 这玩意写完， issue 会堆成山， 完全没有睡觉的时间了。

30

scala 有尝试ensime么？我看近期又有个release

31

不知道楼主解决问题了没有。我最近按照 lsp 官方文档给出的建议优化 lsp mode，Performance - LSP Mode - LSP support for Emacs ，效果还挺不错。

背景：我用 spacemacs 自带的 lsp mode 打开一个大型 c++ 工程（大概五十万行c++代码）写代码感觉卡顿很严重，浏览代码定义跳转还好。

我先按照官网改了一些简单的配置，然后转变用 gccemacs （编译 elisp 为原生代码）后发现效果很好。现在写代码起来顿挫感很少，代码提示也挺流畅。现在基本满足使用需求。

最后我还没有设置使用 plist。如果之后又碰到卡顿情况，或许会尝试一下。

3 个赞
32

之前测试过, 卡顿是因为lsp server返回的json数据太多了, 而emacs解析这些数据的线程跟UI是同一个线程, 所以就导致卡顿.

就像给emacs吃太多, 撑死了, 需要有一个机制来控制这些数据的数量.

VSCode不知道是怎么实现的, 猜测lsp client是运行在独立的线程中, 事先解析好数据给UI用, 所以对UI影响不大.

33

VSCode是多线程处理的。Emacs新版本中json解析是c语言写的库，加上上面给出的lsp性能优化配置，日常的补全解析等都不存在问题了，如果用gccemacs还有一定效果。

2 个赞
34

还是单线程模式, 对cpu性能有一定要求吧? 太老的电脑可能效果不佳

35

新版本性能提升确实很大，我用macOS 平台的 Emacs 29 开启native-comp 的情况下，通过 eglot + clangd 打开 emacs 源代码，一点不卡。eglot 基本就是用默认设置。

36

是的，lsp-mode基本也没问题，前提是配置好，关掉一些不需要的功能就行。

37

我感觉lsp-mode会是未来的主流，基于正则的tags只是lsp-mode的一个子集。那么elisp是不是应该到了一个历史时刻，应该考虑加入多线程了？

38

其实吧， Elisp 在emacs 26 的时候已经加入多线程了，嗯…

一中文版介绍：