服务器云ide_语言服务器协议如何影响IDE的未来

服务器云ide

The release of Visual Studio Code single-handedly impacted the developer ecosystem in such a way that there's no going back now. It's open source, free, and most importantly, a super powerful tool.

Visual Studio Code的发布以一种无可匹敌的方式对开发人员生态系统产生了单方面的影响。 它是开源的，免费的，而且最重要的是，它是一个超级强大的工具。

But with VSCode, Microsoft gave life to another super important thing back in 2016, which is less well-known. It is called Language Server Protocol.

但是，借助VSCode，微软早在2016年就实现了另一个超级重要的东西，这鲜为人知。 它称为语言服务器协议。

什么是语言服务器协议？ (What is Language Server Protocol?)

Language Server Protocol (LSP) is a protocol or a way of talking to language servers (just like HTTP or FTP).

语言服务器协议(LSP)是一种协议或与语言服务器对话的方式(就像HTTP或FTP一样)。

Language servers are special programs that run on regular servers. They take in the meta state of editor in which you're coding (for example, where your cursor is currently inside the editor, which token you're hovering over right now), and return a set of actions/instructions – what token should appear next, what should happen when you CMD/Ctrl-click that token, and so on.

语言服务器是在常规服务器上运行的特殊程序。 它们采用您正在编码的编辑器的元状态(例如，光标当前位于编辑器中的位置，您现在将鼠标悬停在哪个标记上)，并返回一组操作/指令–应该使用什么标记出现在接下来，当您按CMD / Ctrl键单击该令牌时会发生什么，依此类推。

This communication happens using a set of rules defined by the protocol. Language Server Protocol could be thought of as a trimmed down version of HTTP and communicates only on JSON-RPC.

使用协议定义的一组规则进行通信。 可以将语言服务器协议视为HTTP的精简版本，并且仅在JSON-RPC上进行通信。

为什么需要LSP？ (Why is LSP required?)

You see those fancy autosuggestion and error messages popping up in VSCode all the time? And how, just by adding a simple extension from the VSCode marketplace, you get all that IntelliSense power for a completely different language like C, Python, Java, and so on? That comes from LSP.

您会一直在VSCode中看到那些花哨的自动提示和错误消息吗？ 以及如何通过仅从VSCode市场添加一个简单的扩展，就如何为完全不同的语言(如C，Python，Java等)获得所有IntelliSense的功能？ 那来自LSP。

Support for autocompletion and IntelliSense for HTML/CSS/JavaScript comes baked into VSCode (just like PyCharm comes baked in with Python support). However, the same support for other languages can be implemented using Language Server Protocol for those languages.

VSCode支持对自动完成和IntelliSenseHTML / CSS / JavaScript支持(就像PyCharm随Python支持一起包含)一样。 但是，可以使用其他语言的语言服务器协议来实现对其他语言的相同支持。

什么是JSON-RPC？ (What is JSON-RPC?)

JSON-RPC stands for JSON Remote Procedure Call. It is an architecture (similar to how REST is an architecture) but with the fundamental unit being a procedure call rather than an API endpoint in the case of REST.

JSON-RPC代表JSON远程过程调用。 它是一种体系结构(类似于REST的体系结构)，但基本单元是过程调用而不是REST的API端点。

Here's a simple payload for JSON-RPC:

这是JSON-RPC的简单有效负载：

// Request
curl -X POST —data '{
  "jsonrpc": "2.0",
  "method": "runThisFunction",
  "params": [ "some-param", 2 ],
  "id": 1
}'
// Response
{
  "jsonrpc": "2.0",
  "result": "codedamn",
  "id": 1
}

In this example we're sending a JSON encoded payload following RPC specification. If the server is configured to handle JSON-RPC correctly, it will execute the method runThisFunction with the passed parameters and return the result in the form as shown.

在此示例中，我们将按照RPC规范发送JSON编码的有效负载。 如果服务器配置为正确处理JSON-RPC，它将使用传递的参数执行方法runThisFunction ，并以所示形式返回结果。

LSP + JSON-RPC (LSP + JSON-RPC)

LSP uses JSON-RPC to communicate to remote server. It follows this:

LSP使用JSON-RPC与远程服务器进行通信。 它遵循此：

Content-Length: <bytes of JSON>\r\n\r\n<json-payload>

To write an example, it'll be like this:

写一个例子，就像这样：

Content-Length: 78

{"jsonrpc":"2.0","method":"runThisFunction","params":["some-param",2],"id":1}

The LSP requires you to pass the Content-Length header followed by 2 CRLF tokens \r\n. When the running language servers like ccls receive this, they'll respond with an appropriate message:

LSP要求您传递Content-Length标头，后跟2个CRLF令牌\r\n 。 当运行中的语言服务器(如ccls收到此消息时，它们将以适当的消息响应：

Of course, in the example above, you can see that ccls says that there is no method called runThisFunction. But you can see that the remote server also responds with a Content-Length header with a JSON-RPC specification.

当然，在上面的示例中，您可以看到ccls表示没有名为runThisFunction方法。 但是您可以看到，远程服务器还使用Content-Length标头和JSON-RPC规范进行响应。

为什么这一切都重要？ (Why does all this matter?)

With the introduction of a formal protocol LSP, Microsoft reduced the famous M x N problem to an M + N problem.

通过引入正式协议LSP，Microsoft将著名的M x N问题简化为M + N问题。

M = Different languages (C, C++, PHP, Python, Node, Swift, Go, etc.)N = Different editors (VSCode, Eclipse, Notepad++, Sublime Text, etc.)

M =不同的语言(C，C ++，PHP，Python，Node，Swift，Go等)N =不同的编辑器(VSCode，Eclipse，Notepad ++，Sublime Text等)

Previously, for M editors to support N languages, you need M*N solutions. That is, every editor had to implement native support for every language differently.

以前，要使M个编辑器支持N种语言，您需要M * N解决方案。 也就是说，每个编辑者必须以不同的方式实现对每种语言的本机支持。

With the introduction of LSP, the editor only needed to implement support for the Language Server Protocol. Once it did, anyone who makes a language server (following the LSP standards) can be seamlessly integrated with the editor, without the editor ever intelligently "knowing" what language it is working with!

随着LSP的引入，编辑器仅需要实现对语言服务器协议的支持。 完成后，任何制作语言服务器(遵循LSP标准)的人都可以与编辑器无缝集成，而无需编辑器智能地“知道”它使用的语言！

IDE的未来 (The future of IDEs)

As more and more languages come out with their language servers, people will have more ability to choose the editor they like best.

随着越来越多的语言与他们的语言服务器一起出现，人们将拥有更多选择最喜欢的编辑器的能力。

No longer will you have to stick to only XCode for Swift development, or PyCharm for Python. Not only this, but LSPs can also be implemented straight into JavaScript to support IntelliSense in the browser like I'm doing at codedamn, a platform for developers to learn and grow! It's an exciting time to be alive!

您将不再只需要为Swift开发而坚持使用XCode或为Python而坚持使用PyCharm。 不仅如此，而且LSP也可以直接在JavaScript中实现，以在浏览器中支持IntelliSense，就像我在codedamn (开发人员学习和成长的平台)所做的那样 ！ 这是活着令人兴奋的时刻！

Peace,Mehul

和平，回h

翻译自: https://www.freecodecamp.org/news/language-server-protocol-and-the-future-of-ide/

服务器云ide