Language Server Protocol


The Language Server Protocol (LSP) is intended to allow interoperability among a broad range of programs:

  • integrated development environments
  • mechanized documentation tools
  • text editors

The protocol is very new (announced in late June of 2016) and "only" a de facto standard. However, it is supported by several substantial players (e.g., the Eclipse Foundation, Microsoft, and Red Hat) and based on solid foundations. There are already several protocol implementations and we confidently expect more to be announced over coming months and years. So, it's certainly worth keeping on the radar.


Here's a precis, adapted from Red Hat's blog entry, "A common interface for building developer tools":

The protocol, based on JSON-RPC 2.0, is an enhanced version of the "language server protocol" from Visual Studio Code. It defines a series of calls and data structures for implementing common, service-based language functionality on programs such as IDEs and text editors.

A JSON-RPC call, as used in the protocol, can either require a response or be a notification. Calls can be initiated from either a client or a language server. For example, the PublishDiagnostics notification is typically initiated by a server to report compile results to an IDE.


Given AxAp's message passing-based architecture, LSP seems like a natural fit. To be a first-class participant, we'd need to map Elixir call, cast, and info messages into JSON-RPC calls and notifications. This would require one or more ports (or other interface processes), but they could probably take significant advantage of existing work (e.g., cloudi_service_api_requests, gold).

At that point, we'd be able to interact with Eclipse Che, Visual Studio Code, etc. It would also be great if the Emacs or Emacspeak folks adopted LSP, but as yet they do not. Finally, we should create (or find) an LSP wrapper for Pygments, allowing it to perform prettyprinting and syntax highlighting as services.

To be continued...


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r5 - 10 Aug 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email