成熟且活跃开发的有 lsp-mode、eglot、coc.nvim。
新的主打性能的有 lsp-bridge、lspce、nvim-lsp。
前面三个功能较为成熟，lsp-mode 的性能问题十分严重，另外两个评价似乎都不错（我本人没有用过）。
lsp-bridge 性能很好，但是功能较为精简，且使用独立的补全后端，要和现有的非 lsp 的后端共用需要给它们写接口。
lspce 性能稍差于 lsp-bridge，功能同样较为精简，兼容现有的 capf。
nvim-lsp 我没有尝试，从基于它的 lunarvim 来看似乎可以实现较完整的功能，包括基于 lsp 的高亮等。性能方面不知道，有同时使用 neovim 和 emacs 的用户分享一下感受吗？
希望 emacs 早日获得一个全功能且高性能的 lsp 客户端。
我补充一点：前端开发有同时多个 LSP 后端的情况，目前只有 lsp-mode 一家支持，希望这个特性早点儿补上吧。
我是无能为力了：Elisp 只是基本会用，能改配置；好多语法都不懂，当然我也会慢慢学习，但短时间内不会有什么代码贡献了。。。
我目前用lsp-mode 感觉速度还可以，尤其是在28.1 以后。 使用的这两年，感觉没啥问题。
同lsp-mode，可能是我开的补全延迟比较高（1.5秒钟）所以没有感觉到卡手。
lsp-mode 的性能问题十分严重 ，这个结论从哪里得来的？
从emacs 28.1开始，如果从源码编译的时候开启 --with-native-compilation 和 –with-json，然后再按Performance - LSP Mode - LSP support for Emacs 中优化下lsp-mode，目前使用下来没有很明显的卡顿，只要不是急性子的话，估计大都可以忍受了。
别的不说，lsp-mode的功能是真的全，lsp协议本来的目的就是尽可能提供接近IDE的体验。lsp-mode尽可能实现lsp协议中功能的思路我感觉倒很是贴合lsp协议设计的初衷。
从目前 Emacs 及 (neo)vim 中的各个 lsp 实现，其性能和完成度表现都如何？继续讨论：
就vim 和 emacs文件编辑和软件开发上的体验来说，vim更加稳健，emacs更加方便。我之前nvim使用的 coc.nvim全家桶，体验非常好，唯一感觉不好的是node作为补全运行环境。后来又全部迁移到nvim-lsp，全lua运行时环境，感觉和coc.nvim差不多。
emacs 之前很早就接触过，但是一直没有怎么使用。由于vim搜索功能没使用到位，以及定制化脚本很难看懂，所以就暂时转到emacs，elisp脚本语言相对来说较规范。快捷键功能、搜索等都集成度很高。
如果vim有emacs方便的快捷键功能和搜多功能 我还是喜欢vim的稳定，稳如老狗
lsp-mode 和nvim-lsp我都用过。当初就是lsp-mode太慢转到neovim了。用着的体验，最快应该就是nvim-lsp了。不过lsp-bridge也很快，几乎感觉不到两者在速度上的差别。
也就是说 nvim-lsp 同时拥有接近 lsp-mode 的功能和 lsp-bridge 的速度吗
neovim内置的lsp跟lsp-mode这类功能全的不太一样。nvim-lsp更像是一个内置库的存在。你所说的功能，都是各个插件实现的，都是基于nvim-lsp这个内置的东西。光有nvim-lsp是不够的，缺什么就找相关的插件，或者自己写。基于nvim-lsp的插件太多了，我感觉应该能满足的你需求。
对于 lsp-mode 的功能完善程度而言，性能还算不错了，其他的框架要做这么多的功能，性能不一定好到哪里去
我用lsp-mode感觉还行啊，把乱七八糟的东西都关掉，单独用补全的话我感觉还可以的；本来输入也没有那么快的手速； 楼主用过哪一种？怎么就感觉lsp-mode的性能问题严重了？哪一种语言？开启了哪些功能？
eglot用着也很舒服，可惜我比较喜欢的breadcrumb不支持，最后还是换回lsp-mode了； lsp-bridge很流畅，但是匹配排序的细节感觉不如lsp-mode，而且和company，corfu都不兼容；我有些配置是依赖company的，实在懒得改了。
现在还是lsp-mode用着；
这个和电脑配置关系比较大，我公司的垃圾电脑（五六年前的 mbp），lsp-mode 卡到没法用（只用补全和跳转，别的功能都关了不用，我也不喜欢），家里的电脑就还在可忍受的范围，项目不大，golang项目10万行以内，python三四万行的样子。lsp-bridge 就完全不卡手。每当有人说 lsp-mode 性能没问题时，我都想让人远程到我电脑上写几行代码试试。。（不过觉得不卡的接着用，觉得卡的换就好了，这种环境差异的问题，也没啥）
当然是在相同水平的硬件下进行比较
这是我回复上面那位的。不过关于这个帖子的主题，我觉得 nvim 内置（也不能说内置）的 lsp 就比 emacs 这些都好用（我不需要太多花哨的功能），luajit 还是快，之前 emacs 太卡，配了 nvim 用了一阵子，虽然不是太习惯，现在 lsp-bridge 出来，就换回 emacs 了
nvim的内置lsp的性能估计是最好的，毕竟是luajit。lsp协议基本上应该也都实现了，但是nvim主流用treesitter做高亮，社区似乎基本都不太在意lsp的语义高亮做的怎么样。nvim-lsp目前也支持多个lsp用于同一个文件，使用的时候比如多个lsp都支持format，会弹出来让你选择使用哪个lsp来format。
话说vim和emacs一样都是单线程的程序，之前看懒猫分析过为什么emacs的lsp性能会这么卡，就是因为elisp的性能不够，会堵住主线程。在nvim里coc和内置lsp其实表现是差不多的，但是coc也是异步架构，vimscript+js，但是我很好奇为什么coc就一点都不卡，非常好奇，理论上来说vimscript应该性能要比elisp还要差很多才对。
再慢的语言，只要有多线程支持，都不会卡手。
emacs的线程本质是和协程类似的概念，只要当前线程阻塞，就切换不出去，不是真正意义上的并发线程模型。
不管什么样配置的电脑， 同时用一下 lsp-mode 和 lsp-bridge ， 就可以明显感受到可用和流畅的区别。
建议直接对比用一下， 感受就很明显。
多个LSP服务器都支持 format 的时候， 每次format或者其他操作都要让用户选择一个LSP服务器， 这样弄不麻烦吗？
只有format需要主动选择使用哪个lsp吧，code action之类的会自动把所有得lsp提供的code action合并到一起，补全的话由补全前端把结果合并到一起。nvim里可以主动选择禁用掉某些lsp的某些功能，这样就可以每个操作都只有一个lsp。
vim其实也是单线程的程序，也不支持多线程。但是coc一点都不卡，是因为emacs的completion-read之类的函数处理补全结果都是在主线程处理才导致卡顿的吗？coc是补全后端前端都是由自己提供的。