哦哦 
真正用 emacs 写过一次 java，确实非常卡，而且越跑越卡。同样的 lsp java 后端，在 vscode 里顺畅得很，目测还是 lsp-mode 的问题
lsp-mode 和 eglot 的补全好像都是基于自带的 CAPF 做的，不知道这个东西有没有类似于 company 的 company-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#的协程，逻辑可以和时间解耦，但是保留控制的权力。并且所有代码转移到多线程版本几乎没有成本
额，线程、协程不是一个东西吧
协程的话，不知道下面这个怎么样，之前见到有人安利过，应该蛮成熟的了。