VSCode 的 debug protocol，跟lsp一个思路。 现在Emacs开始支持了：
5 个赞
今天作者給我看這張screenshot
You may ask them what debugger they would like to integrate next, for now I have Java and Python
可能是lsp-mode + lsp-java + dap-mode的效果，需要workspaceFolders支援，見這個PR
所以奔走相告下～比如Ruby TypeScript Go
10 个赞
话说这里的“他们”指的是谁，此外，这个PR我也入镜了，然而我elisp写的也不多，感觉你可以@一下老王来看elisp 
最近在研究 lexer, parser, llvm, 估计写 elisp 插件的时间都没有了.
完成度已经这么高了么，刚好试了一下 lsp-java，好像体验不输 meghanada 了。
哪个lexer? antlr flex gcc clang
更 llvm相配的应该是clang
玩llvm的話可以和我討論～
我幾乎每天git pull編譯llvm(而且爲了折騰ccls不得不學clang，應該倒過來說爲了學clang不得不折騰ccls(提供了契機))
貌似这货需要lsp-java？有没有独立的Java debug server?
问一个跟 LSP 有关的问题，我知道虽然从具体实现的角度来说做到了 M * N -> M + N，但是这个从接口上来看，每个编辑器依然需要安装单独的语言插件，即插件总数依旧是M * N。那么有没有一个中转的接口平台，可以让编辑器前端和语言后端只跟该平台通讯，从而消灭繁琐的接口矩阵？
lsp-mode就是这样的啊，你去看lsp-python lsp-ruby里面都只有几行配置的代码
但是对于其他编辑器来说（比如 VSCode），可能需要专门在 marketplace 上发布一个插件。况且不同语言服务端的启动方式也不尽相同，如果要支持的更多编辑器，每个语言每种编辑器开一个 repo 来维护，最后劳动力还是落在了服务端的开发者上。
你的编辑器插件还是要和平台通过接口交流啊……
不太明白你说的这个平台是怎么简化编辑器端的。
另外同一编辑器不同语言的“启动方式”是一样的。
其实很简单，只需要提供一种 client 端的配置规范，让所有编辑器的 LSP 插件去解析就行。比如
{
"c++": {
”server": "ccls",
"path": "/path/to/ccls",
"startargs": ...,
},
"python": {...},
...
}
- 无论何种编辑器也只需要一种配置，即不同语言服务端的启动参数，client 的插件预先完全不需要知道。
- 某种语言可能存在多种服务端，比如 C++ 就有 Clangd, cquery 和 ccls, 用户可以通过修改 json 快速选择，不需要通过禁用/启用插件来进行。
既然 LSP 的主旨就是要消灭 M * N， 那么只需要再激进一点，把 client 端的配置文件也一并规范了，应该能做到真正的 M + N吧。
你一开始说平台，怎么又跑到配置上来了？
首先，目前lsp-mode就是这样的，lsp-mode是具体实现，lsp-language是配置。
插件作者并没有给每个语言和每个语言的backend单独写一个完整的lsp客户端，他们又不傻，我觉得你不用担心这个。
配置文件本来也是规范的，只不过每个编辑器的插件具体是实现的时候会有差别。
我一开始说的平台，只是设法集成一些其他的功能罢了。如果这些额外的功能都去掉， 单纯来讲，只需要一个统一的配置文件，你大可忽略前文的平台。
按照你的说法，如果我现有一个 langserver 的 repo，在不提供 VSCode 插件 的情况下（我指的不是 LSP 中的 client 功能实现，毕竟 VSCode 自带 LSP client，而是配置每个语言的 server 所需要的插件）用户能否直接通过修改配置文件来设置 server 呢？换成 lsp-mode 也一样，用户要如何在 Emacs 中进行配置呢？
在这样的情形下，用户是否既要关心编辑器又要关心语言服务端？
eglot不装别的
你这又转到用户了…
你可能是对的，我不评论了。
Practice your idea, or it evaporates.