你提到的这个实际上是VSCode做的烂的地方（extension系统设计的很奇怪，使得无法实现一个通用的 LSP Client 插件），eglot并不存在你说的这个问题。
我看了一下 eglot 注册服务器的方式，其实 vim, atom 也都是这样，每一种编辑器社区其实多多少少都在手动维护一些主流的语言配置的包（比如 Atom），并且声称用户可以自定义配置。但理想上，这些配置本来应该由服务端提供而与具体的编辑器无关。
另外，请教一个疑惑，不同语言服务端的启动参数是否有规范，是否有规范文档链接？我指的不是 JSONRPC的规范，比如 eglot 中的 “—tcp port” 是所有 langserver 都自带的吗？
“如何与 language server 通信”本身就不是标准定义的事情，用户在 eglot 中使用一个新的 language server 的时候，实际上大部分就是在配置“如何与language server通信”这一点（另一点是initializationOptions）。与language server通信可以有很多种方法，是和每个用户的使用方法密切相关的，写在标准里没有任何意义。比如现在的 language server 大多是由编辑器拉起来的，使用 stdin/stdout 和父进程（编辑器）通信，如果把这一点写进标准里的话，那标准是不是还得写一下什么语言用的 language server 叫什么名字，这个 language server 应该放在哪个路径这种事情？如果不写的话，你是不是还是得自己配置这些东西？
initializationOptions不是不想有规范，而是没法有规范，很多不同的 language server 都把它用来作为传递 language server 特定的配置使用，而这些配置本身又是和特定的语言甚至language server强绑定的，放进标准里也没有意义。
你所说的和我认为的规范也许并不矛盾。如何启动挂载服务器应该由服务端来说明（比如传入什么样的参数，如何设置 path, port, initializationOptions 等等），这些应该都是与编辑器无关的内容，编辑器唯一需要做的是安装 lsp-client 插件，让插件解析这些配置（从 Server 的 Readme 里复制粘贴、做做修改、保存在编辑器配置子文件夹下即可，可以是json）。换句话说，就是让 lsp 客户端的配置与编辑器配置独立开来，不需要 M * N 的维护量。很多冷门的服务端与编辑器（比如前文的MSBUILD） 里压根就没提怎么挂载服务器。
先形成事实标准再形成文档规范。 没有人懂任何语言，包括微软。 所以，现在lsp已经有一定标准基础，更完备的标准要从实践中演进，而不是顶层设计好，做不到
2 个赞
那也只不过是换了一种格式化的方式写 README 了而已，而且为了满足每个人的需求，总还是要改的，不可能复制粘贴一下完事，一样不可能做到开箱即用。
又注意到一個新奇的玩意兒，Build Server Protocol
https://github.com/scalacenter/bsp/blob/master/docs/bsp.md
啓動參數不應該有規範。adapter避免不了
喜欢写代码、调试、构建搞在一起是IDE惯出来的把。我觉得自己多开几个会话分别干这些事挺好的。
1 个赞
dap gdb 怎么用，有教程吗
- Download the vscode extension (make sure that
dap-gdb-lldb-debug-programpoints to the correct location). - Do
(require 'dap-gdb-lldb)
3.M-x - dap-debug and select the gdb/lldb template(it will ask you to select program to debug).
vscode extension吗