所以如果我有时间和能力，我会优先考虑改进 language server，而不是造别的工具，这样受益的人更多。 当然这只是个人喜好，做自己想做的就好啦。
是啊，我其实也是在想解决问题，用的也是“服务”这个概念，不过这个“服务”和LSP里面的“S”比起来是更加广义上的“服务”。
把“服务”这个概念拓宽到软件层上，某个软件提供一种“服务”，别的软件也能调用它，就是这个样子。
总之，大家按照自己最擅长的方式做事情吧
Just do it!
我是认为，基本概念弄错了，会把简单的事情复杂化。
3 个赞
.dir-locals.el 也可以考虑，使两者既可以独立，又可以针对一个 project 进行协作。 这种协作，在 Mac 下使用多桌面的切换，会显得方便些。
想起了 edit-server.el 及 atomic-chrome，这些在浏览器输入框中跳转到emacs编辑后又返回的工具，EVS是不是也和这些工具原理有相同之处，只是把浏览器换成了vsc
我希望有一天可以把自己的 meow 移植到 vscode 上面。
1 个赞
有个 Dance,就是貌似不是很好用。
虽然c#后端有OmniSharp 但是开发unity的体验还是挺差的。另外，今天vscode写了一点unity的代码，发现vscode 真的就非常的流畅，就算是emacs上最快的lsp-bridge也没法媲美。
差距在哪？ 是 VSCode 在 LSP 之外还有额外的功能？
移植的话就肯定是要零依赖，不然就很重量级
在查找函数定义，还有引用那边。这个就比较复杂了，因为unity里面有的代码存在meta里面？lsp 在查找函数定义的时候就会找不到（lsp 返回空）。流畅的话，其实去试试就能感知出来了。
vscode 的c#插件似乎走的不是lsp那一套.
虽然lsp协议是微软提出来的，但是微软自己家给vscode使用的插件很多都是夹带私货的，很多都不遵循自家的lsp协议和dap协议。
比如python，vscode使用的插件是由pylance提供的服务，pylance闭源而且不允许非vscode以外的编辑器使用。pylance比pyright的一点显著的大进步是，它可以同时显示类型签名以及文档，pyright的话，如果一个函数有类型签名，那么就不会显示文档。微软官方将之视为pylance的feature，明确表示不会给pyright提供。Show documentation when entering arguments of a function · Issue #1280 · microsoft/pyright · GitHub
vscode官方的typescript插件是tsserver，而不是type-script-languga-server，它并不遵循lsp协议，typescript-language-server有性能问题，体验要比tsserver差很多. tsserver should implement the Language Server Protocol · Issue #39459 · microsoft/TypeScript · GitHub
同时，vscode-js-debug这个插件也并不遵循dap协议，因此别的编辑器也不能直接使用。help setting up vscode-js-debug · Issue #82 · mfussenegger/nvim-dap · GitHub 比如这个 issue 的问题，vscode原先支持 dap 的 node-debug2 插件已经停止维护。
不过这个毕竟是微软，这种名义上搞开源，实际上夹带私货这种事情，一点都并不奇怪。作为对比，谷歌推出的 gopls 就是标准的 lsp，并不搞私货，主要由苹果维护的 clangd 也是标准的 lsp。
7 个赞
这种开源的形式，结果就是微软自己开发的语言服务器其他编辑器不兼容，社区、语言开发的语言服务器 VSCode 能完美兼容，VSCode 成最大受益者，只能说不愧是微软
1 个赞
是的，我觉得python微软搞个pylance也就罢了，毕竟python还有pylsp是社区维护的，typescript作为微软自己维护的语言，做个tsserver只有vscode能用是最搞笑的。别的公司自己维护的语言咋都支持标准的lsp。苹果的swift基本上只用来做GUI所以基本上只用xcode来写，它们也做了一个标准的sourcekit-lsp。
hi，请问这个配色叫什么呀？
挺有趣的概念，我可以具体的理解为“在emacs和vscode中同步打开的文件和编辑位置并互相跳转”吗？
那么或许可以实现一个协议，通过插件等方式，接入各种编辑器和IDE，获取当前打开的文件和编辑位置，并在其中同步。