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

哦哦 :joy::joy::joy:

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

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

参考下 GitHub 的这个 Issue

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

根据我的折腾经验,原生编译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

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

哥,就等你了

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

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

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

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

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

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

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

3 个赞

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

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

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

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

2 个赞

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

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

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

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

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

一中文版介绍:

简单看了一下,似乎还不太成熟?否则lsp-mode的作者为什么不考虑呢? 我个人感觉最理想的多线程方案应该是C#的协程,逻辑可以和时间解耦,但是保留控制的权力。并且所有代码转移到多线程版本几乎没有成本

额,线程、协程不是一个东西吧

协程的话,不知道下面这个怎么样,之前见到有人安利过,应该蛮成熟的了。