是不是对于一个语言来说，还是要么使用 VSC 要么使用 Emacs?
我只是纠正的你概念性错误，和你的结论无关
OmniSharp官网看看，人家支持Eamcs也支持VSCode，只不过对于VSCode客户端做了优化，所以VSCode能做的LSP，Emacs做不到，虽然他们都在用OmniSharp，但就结果来说，Emacs的就没法用，因为相关LSP客户端的就没人做。
再简单点说，如果你一开始就站在拿Emacs怼天怼地的角度看问题，那就当我没说。
简单来说，谁有本事谁上，不限制任何编辑器，不拒绝任何IDE，不拒绝任何软件，只要他们能无缝衔接，能够达到让编辑文件的用户得到最优体验，能让“编辑文字”在特定场合的特定需求能被满足，那么这就是最优的服务。
再简单点说，我是不会拿Emacs跟人聊天灌水发送文件的，我同样不会拿钉钉文档写代码的。因为它们最擅长做的事情本来就不一样，最适合的场景用最适合的服务。代价最小。就是这个意思。
如果要写Clojure，我一样不会选择用VSCode，拿Emacs写Clojure的体验VSCode也没法比。Emacs是一个非常优秀的Clojure IDE，因为有开发者用户给它赋予这种能力，不过并没有用户给它赋予良好的Unity编辑生成环境，因为据我所知，喜欢用Emacs还是个Unity游戏开发者的…群体巨小。但喜欢VSCode的，还是Unity游戏开发的…给你看张图
所以，整个开发的生态不应该是割裂开来的，应该是融合起来，无缝衔接，用户在特定编辑文字行为时能够体验到最适合的编辑体验，这就是拿服务理念看待软件啊。
不知道你看没看过Chromium的源代码…额，那是个哥斯拉一样的项目，简单来说，主流的IDE编辑器都不适合拿来看它的代码。那什么最合适？答案是谷歌自己家就做了一个专门阅读它代码的网站： 在这里👉🏻 https://source.chromium.org/chromium 你用它去阅读Chromium源码，跳转，引用查找，体验是非常舒服的，简直就跟用IDE看小项目源码，完全没有两样，整个网站可以说就是一个IDE服务。这也是谷歌公司赋予网站的一种服务啊，可以给用户很舒服阅读它源码的服务。这种时候我既不会拿Emacs看代码，同样不会拿VSCode看，我会选择直接用谷歌自己家的网站，因为那就是我能找到的最优的服务。
目前的软件环境是，虽然各种服务都有着各种优秀的体验，不过相应的问题也是非常严重，因为服务与服务之间就是一种割裂的状态，而作为用户，想切换一种服务，代价也是非常巨大的。那频繁的切换服务，还要像在用Emacs的某种mode，那简直就是在开玩笑。
所以…举个例子：我们要做的是服务的无缝衔接，就比如说，不是拿Emacs直接去订外卖，而是能在美团里面开发一个深度链接，想订外卖的时候，Emacs一个快捷键直接调用这个深度链接，直接唤起美团App，在App里面点该点的外卖，等用户点完外卖，关闭美团App的时候，一个按钮直接点击回到Emacs之前的编辑上下文里面。这才叫美好的体验。
这就是服务的无缝衔接，能获得最优的服务体验。
现在这个时代不是没有软件，不是没有解决问题的方案，都有，而且很多，而且很多都在打架撕逼，挤破脑袋，争着抢用户，谁都想要统一全天下。其实吧…不管是谁，不管是哪个社区，不管是那个公司，大家精力都有限啊，做到的事情也很有限啊，把自己专注的服务做好。还能和别的软件融合起来，这才最应该做的事情啊。当然不是考虑怎么才能在Eamcs做到能打LOL的这类的事情啊。
Just Try To Live In The Real World, No In Any Software!
再说一次，lsp 客户端大家都一样，lsp 那个 p 叫 Protocol， 你不去实现 Protocol 里的内容，就不叫 lsp 客户端。这是概念性的错误，和别的没关系。
我也是这么认为的。LSP server是一样的情况下，理论上效果也是一样的。差别就是配置不一样。
楼主这个方式是一种选择吧，喜欢就点赞，不喜欢就pass。
不要和lsp绕在一起吧，不是同一纬度的。
大家没有必要为自己的选择据理力争，包罗万象才是emacs的魅力。
不太清楚你希望表达什么，我清楚的是没法用Eamcs开发Unity。
编辑器里面跟LSP对接的模块你们都管它叫什么，我不太清楚。
我管它叫客户端，你要是觉得我的说法不专业，那我就管它叫某个编辑器对接模块好了。
这个编辑器对接模块，对于在某个编辑器里面使用LSP的用户而言，但它是个很重要的模块，而且，这个模块的开发是个坑，开发它是有很大的工作量，就算开发完成，它同样是个很大的坑，维护的工作量也并不小。
在Emacs这边，和Unity对接的，那个模块压根就没人填上。但VSCode那边有人填，而且填的不错。后台同样都是一个OmniSharp。
跟概念没关系，想清楚一开始要做什么事情啊。我并不在乎什么什么形式，也不在乎什么现有观念，能做到最好的体验就是目的
不是针对LSP怎么怎么样，就只是从用户需求的角度上去看待软件。具体实现方式大家各有所长，选择自己喜欢的就行。
就是你对 lsp 有一些误解。把你所说的的 “lsp 客户端” 替换成 “vscode 插件” 差不多意思就对了。我也明白你实际想表达的意思，我只是想纠正一下概念性问题。
在Emacs这边，和Unity对接的，那个模块压根就没人填上。但VSCode那边有人填，而且填的不错。后台同样都是一个OmniSharp。
你的误解就在这里，VSCode 那边后面根本不是简单的对接 omnisharp-roslyn language server。
GitHub - dotnet/vscode-csharp: Official C# support for Visual Studio Code 这个 VSCode 插件并不只和 lsp 对接，它自己实现了很多别的功能，你可以去翻它的代码。
就是说 VSCode 在 Unity 体验上好和 lsp 没多少关系，完全是 VSCode 插件那边功能多的原因。
非常感谢指正🙏🏻
是的，总之呢，在插件生态上其实就是个巨坑，不管叫它啥，要是用户群体不够多，支持不到位，非常影响开发体验。
因为我们Emacs很小众的原因，所以，也不会有人愿意去开发这样一套插件，所以嘛，我会换个角度考虑怎么开发体验最好的问题。
这就是 lsp 的意义所在。有些功能可以放在插件中做，也可以放在 language server 中做，所以让所有编辑器受益的办法是，尽量放在 language server 中实现。
这个愿景那是真美好，不过，要真正落地，那恐怕一点都不简单啊。不然也就不会有今天我们的这个讨论了😂