我有一个1300多行的vue文件，输入的时候vls补全一次大概需要5s，比较了vscode、vim+coc.nvim以及emacs，只有emacs会输了几个字符之后就无法上屏了，只有等补全结果返回之后才有反应，因为 company的补全也声称是异步的，为啥会出现交互卡顿的情况呢？？
经测试如果后端秒回的话是不卡的，所以肯定不是 lisp 处理消息慢的问题。
简单对比了一下三个编辑器：
-
vscode 和 coc.nvim 在输入的时候都是只触发一次补全（具体vscode是不是只触发一次，只是看打印lsp log来推断的），而coc.nvim 的介绍里面是提到了的；
-
而emacs的实现是每次触发新的请求都会取消上一个请求，对于这种后端很慢的情况，就成了恶性循环，每次都触发新请求的话，那啥时候也补全不上，而且还会导致后端要连续处理好几个耗时很长的任务。
所以，想问问emacs有类似的方案吗？只触发一次，如果要补全的内容差不多，比如a和ab，ab直接复用a的请求，等请求回来再前端过滤一下直接去补全，实际可能会更负杂，但是持续触发新的请求感觉更影响体验。
另外，再咨询下，company-mode 的异步是使用定时检查来实现的吗，emacs-lisp 貌似也支持 Promise ，好像 company 也没使用这种方式。
我也遇到同样的问题，非常非常卡，楼主有找到解决方案吗？
Lenic
3
卡顿的时候，你看下 Emacs 内存占用。如果我理解没错的话，此时你的内存占用会非常高，有可能高达 1.5G。
此时最简单的做法就是完全重启 Emacs。
lsp-mode 的实现和性能都太差，看着支持语言很多，整体架构没设计好。
等我下半年有空，基于Python和多线程设计，设计一个新的 lsp-bridge
- 对LSP Sever主要做好汇总、容错和性能管控
- 对Emacs实现一个支持多后端（不仅仅是LSP,还包括 yas 等）的高性能前端，前端可以用Qt来实现
从高性能的角度来设计整个补全框架，补全一旦卡，支持再多语言都不想用。
16 个赞
你是多大的项目，我用 gopls 改 Prometheus 代码，比较流畅
之前讨论过，目前json解析似乎并不是瓶颈了，因为Emacs引入了原生的libjson。
不过到目前为止，我用自己的Centaur配置，还没有遇到楼上说的如此严重的性能问题。日常使用的项目规模也不算小，第三方库也很多，不知道是否与配置有关。
和电脑性能关系很大, 我在台式机上感觉一切都很快.
我现在一直用的 doom-emacs ，16G内存的macbook pro，大文件的时候依然会出现卡的情况卡的时候编码体验老差了 
补全的慢还可以接受，但是补全慢的时候都影响上屏，明显感觉到敲一下字母卡一下才出现，就很难受了
台式机32G体验确实会好不少
啥时候 emacs 的补全体验能达到 vscode 的效果就完美了，用emacs习惯了之后换到vscode、vim，各种适应不了。。。
2 个赞
上面都说了用的Centaur Emacs，搜一搜又不费事儿。贴多了又会有人说做广告啦
kinono
17
歪个楼，不嫌弃 ctags 的话可以试试 Citre
1 个赞
我也安这个了 
前端天天写js/ts/vue/react的那一堆库 lsp 还舍弃不了。。。
对于lsp server反应慢的情况, 可以把company-idle-delay设置大一点试试, 比如1
kinono
20
我不懂前端啊，但是可否试一下把你用的库和工程一起扫描了？ctags 扫描的时候可以添加外部库的路径的。
