lsp-ui可以关掉，或者部分关掉。其实我猜测你说的主要是lsp-ui-sideline吧
受教了，这个有什么测试数据吗？如果用 Rust module 能避免？
我也不喜欢lsp-mode，乱七八糟的东西太多，每次从一个新位置打开文件都要停下来问你是否要导入项目，超级烦。
现在又用回eglot了。比较欣赏eglot的极简哲学，只提供必要的lsp协议集成，其他的东西都尽量留给现有的Emacs设施: xref, flymake, eldoc等，从来不问没必要的问题。
其实我希望楼主能够帮助改进eglot，因为毕竟有很大一部分工作eglot已经做了，再重做一遍感觉比较浪费。当然楼主100%有权决定自己的时间要花到哪里，如果能很快超过eglot的完成度的话，我也很乐意改用。
1 个赞
我是针对你说 eglot 体验不好说的。
一个月前lsp-mode作者和eglot作者在r站上对骂起来了，这混水不好蹚啊 
1 个赞
来个地址看看？
另外似乎不是第一次开战了
邮件列表里有人写了一个针对 java 的插件，我没用过，或许可以试试看。
https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00056.html
可以透过Emacs内建的completion-at-point-function机制实现补全（印象中eglot, lsp-mode都是这样做的），Company有一个company-capf后端可以直接使用completion-at-point-function的结果。这样不用自己写一个company后端，其他Emacs插件也比较好整合。
这玩意儿不是一个包，而是改的 emacs 的代码？
笑死，他们本来在issue里就快打起来了
LSP协议我觉得用其他语言实现反倒会更快一点, 因为lisp里的结构体, list, alist以及hash table 真不如其他语言里的结构体, 数组和map用起来简单方便. 多会话之类的管理起来也挺痛苦, 而且不能真并发. 所以lsp用其他语言比如golang或者rust开发起来可能更快. 当然最主要是更高效.
1 个赞
用 rust 实现性能是毋容置疑的，我指的是复杂度。功能多就会带来复杂度，少了用户体验又不会好。这需要平衡，很考设计功力啊。懒猫准备来克服这个难点吧
json解析的数据量多了关系就大了, 主要是因为emacs的单线程, 解析不是异步的.
之前用过dart的lsp, 极卡, 调试发现, lsp server给过来的补全数据太多了, 一下来上万行, 能卡几秒.
如果数据的接收和解析都是异步的, 解析后再限制一下补全结果数量, 然后再给传给emacs, 这样应该会很流畅.
对eglot来说, 协议通信好像用的jsonrpc库, 如果jsonrpc库用动态模块在异步线程实现, 性能应该会好很多.
包括复杂度, 我感觉lisp实现复杂的协议挺麻烦的, 远不如golang, golang比较适合做复杂的通信协议. 包括c++, 我觉得都会比lisp开发起来快. 当然, 可能我对lisp不够熟悉.
这个不好讲，有些用 lisp 实现很方便的，但和一般语言差别有些大。
印象中, lsp-mode的issue里有人提过用动态模块实现lsp的想法.
嗯嗯，我关掉了lsp-ui; 不知道是不是最近有更新，感觉会在底部提示很长的函数使用，我其实不需要，但不能关掉，很抱歉还没有认真读它的readme。
其实我用lsp很多，在python，在c++，也用dap和它配合，感觉还不错；在python上提示，比ananconda-mode要全面。
目前市面上各种服务和复杂协议几乎都是其他语言实现的, 整体经验和库肯定要比lisp成熟很多, 从这方面来讲, 开发效果几乎可以肯定会超越lisp.