Skip to main content

Language Server Protocol

For an Editor supporting features like code auto-completion, go-to definition and ,any other intelligent function is a challenging and time consuming task, because it requires writing a domain model which includes a scanner, parser, and many more. Language Server Protocol is a new technology used by many Open Source Editors. It enables autocompletion, goto-definition and other intelligent code functions to be offloaded to a dedicated server for the language currently being written.

Origin of LSP

Language Server Protocol was developed by Microsoft for Microsoft Visual Studio Code. Visual Studio Code's debut has had such a profound impact on the developer ecosystem that there is no turning back. Later on it is adopted by many companies, In 2016 Microsoft, Red Hat, and Codenvy have announced a collaboration to standardise the protocol's specification. Its specification is hosted and developed on GitHub.

How does it work

A language server runs library in its own process and use inter-process communication to communicate, A protocol is made up of the messages that are transmitted back and forth over JSON-RPC.Communication between tool and language server works like,

  • The User opens a file in the tool: When the tool detects that a document is open, it sends a notification to the language server. The truth about the contents of the document is now preserved in memory by the tool rather than on the file system.
  • The user makes edits: The language server updates the semantic information of the programme after the tool alerts the server about the document modification. As a result, the language server analyses the data and tells the tool of any mistakes or warnings that have been found.
  • The user executes "Go to Definition" on a symbol in the editor: The tool makes a request to the server with two parameters: (1) the document URI and (2) the text location where the Go to Definition request was made. The document URI and the location of the symbol definition inside the document are returned by the server.
  • The user closes the file: The tool sends a notification to the language server, alerting it that the document is no longer in memory and that the current contents are up to date on the file system.

lsp-flow-diagram

Is Language Server the Solution?

When we came to considering IDE tool support, we discovered that creating tools/plugins for each of the IDEs was a time-consuming effort. Then we came upon this fantastic Language Server Protocol solution. Language Server Protocol requires two parties to comply with the protocol specification: a client and a server implementation. The server implementation exposes IDE features such as auto-completion, document symbols, and go to definition. Any Language Server client can easily embed the server implementation, and all clients behave in the same way during each operation. So the answer is YES to to use the Language Server Protocol for your Language and for your client.

Conclusion

We have studied the LSP and how it brought the change in the world of IDE's to make them more convenient and easy to use for development, Below are some main points discussed above:

  • LSP allows you to share a set of IDE features across several IDEs/tools.
  • Maintain consistency by LSP across diverse tooling environments by using the same capability behaviour.
  • There's no need to implement the same feature for each client.
  • Maintaining a single server implementation rather than multiple ones for different clients.