The Language Server Protocol in a popular IDE-independent and Language-independent interface to provide and consume language edition services - such as code analysis, completion, hyperlinking... It basically lets the language providers implement the protocol as a server, and the IDEs consume the protocol as a client to have the IDEs presenting the language-specific data without having to know about the language.
This protocol already has multiple successful stories. In this talk we’ll demonstrate:
* How a C# language server can be used in Eclipse IDE (thanks to LSP4E) to provide rich C# edition capabilities
* How a Java language server implemented on top of JDT is integrated into VSCode to have VSCode supporting rich Java edition capabilities
* How you can easily write a language server in Java (with LSP4J) and plug it into Eclipse IDE (with LSP4E) and VSCode and demonstrate how easy it becomes to ship additional features for your language in all tools at once.
Presentation on how to chat with PDF using ChatGPT code interpreter
[EclipseCon France 2017] Language Server Protocol in action
1. Hey language, please add support to the hypest IDE/editor of this day!
Hey IDE/Editor, please add support for
the hypest language of this day in your
IDE/Editor !
DONE !DONE !
Language Server Protocol in action
...15 minutes later…
4. Hey language, please add support to the hypest IDE/editor of this day!
Hey IDE/Editor, please add support for
the hypest language of this day in your
IDE/Editor !
DONE !DONE !
Language Server Protocol in action
...15 minutes later…
5. Preamble - Lexic
● By language we only mean Textual Language
(ie any text with constraints) – at the moment...
● Ad-hoc languages (without constraints pre-
defined, but with constraints we can learn from
the language) are valid languages
● A server is any application that provide a
service. It can be local or remote, using
transport of its choice (not only Web nor
remote).
6. Integrating edition support for one
language in one tool
● Requires good knowledge of the language and its technical stack
– How to parse it
– How to do semantic analysis
– Usually a type system
– …
● Requires good knowledge of the tool and its technical stack
– What are the usual workflows and UX
– What is the development style, what are the APIs?
– …
Difficulty:
Tool and language experts
7. Java JS TS C# Yaml JSon Ceylon Go ...
Eclipse
IDE
3 3 3 3 ... ... ... ... ...
VSCode 3 3 ... ... ... ... ... ... ...
EclipseCh
e
3 3 ... ... ... ... ... ... ...
Emacs 3 ... ... ... ... ... ... ... ...
NeoVim ... ... ... ... ... ... ... ... ...
Gnome-
Builder
... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... ...
M languages
N IDEs/Editors
Total cost:
• O(M*N) difficult integrations
• Not usually designed for separation nor reusability as technology differ a lot
→ can drive to inconsistencies in tools
120
8. Enters the Language Server
Protocol
Language Server Protocol
Difficulty: Difficulty:
Tool
Language/Framework
Logic
consumes implements
<<interface>>
Tool experts Language/Framework
experts
9. Protocol insights
● Initiated as part of VSCode, by emeritus Eclipse
IDE contributors
● OSS and community driven aware
– Github
https://github.com/Microsoft/language-server-protocol
● Request-response and notifications based (over
JSON-RPC)
● Transport not constrained: can be stdio, IPC,
UDP…
● Deployment not constrained: local thread, local
process, remote connection...
10. Clients interact with a Language Server
● Clients simply connect to the language server
input and output (that may involve starting the
language server, or not)
● Then clients orchestrate requests and read
response/notifications on JSON-RPC over those
streams, and define how user interact with those.
12. Example of communication
● Request for hover
{
"jsonrpc": "2.0",
"id": "27",
"method":
"textDocument/hover",
"params": {
"textDocument": {
"uri":
"file:///home/mistria/runtime-
demoLSP/mess/style.css"
},
"uri":
"file:///home/mistria/runtime-
demoLSP/mess/style.css",
"position": {
"line": 1,
"character": 2
}
}
}
● Response for hover
{
"jsonrpc": "2.0",
"id": "27",
"result": {
"contents": [
"Sets the background color of an
element."
],
"range": {
"start": {
"line": 1,
"character": 2
},
"end": {
"line": 1,
"character": 26
}
}
}
}
13. Turning the matrix into a star
Eclipse
IDE
VSCode
EclipseCh
e
Emacs
NeoVim
Gnome-
Builder
...
N IDEs/Editors
Total cost: O(M + N) integrations
• Designed for separation, distributed work and reusability
• Accessible one can decide to only work on the layer they’re skilled at
• Enforce consistency of language supports in tools
Java
JS
TS
C#
YAML
JSON
Ceylon
Go
...
32
2
2
2
2
2
2
2
Language Server Protocol
2
2
2
2
2
2
2
2
14. Language Server “SDKs”
● Libs already exist in multiple languages to create
language servers or clients.
● They typically map operations and entities of LSP to
APIs and Data Types.
● Eclipse LSP4J is a Java API to produce Java-based LSP
clients or servers.
15. Benefits for Eclipse technologies
● Ceylon, Xtend, Xtext, EMF... can implement the
LSP in their SDK and enable code-assist in
many tools at once
● Frameworks or tools that build on top of
languages can also provide additional
hints/static analysis/linters
● IDEs can implement support for LSP to easily
support many languages
16. Demo
Language
Server
Protocol
Demoed and detailed
at
+3 others so far:
Atom, Monaco, Gnome Builder
+20 others so far:
PowerShell, C++, JSON, CSS/LESS/SASS,
PHP, Haxe, RAML, API Elements, groovy,
SQL, Ocaml/Reason, Go, Rust, Scala, Polymer,
Julia, Python, Isabelle. GraphQL, ember
17. Demo debrief (1/2)
In ~20 minutes we:
– Showed CSS/HTML/C# integration in Eclipse IDE is a
matter for a few basic lines of Java and plugin.xml
– Edition using language server is comfortable and can
quickly be better than edition with unmaintained editors
– Showed VSCode integration for language servers is
simple too
– Showed Java integration in VSCode is powered by
Eclipse JDT Language Server
– ….
18. Demo debrief (2/2)
In ~20 minutes we:
– ...
– Showed how easy it is to create own language server with
Java and Eclipse LSP4J (just implement a few interfaces!)
– Showed how a home-made language server can very
easily be integrated in Eclipse IDE and VSCode
– Modified the language server and showed how tools can
take advantage of iteration and new features without effort
19. Not convinced yet? With 10 more
minutes...
● We could have shown a similar demo with any
of Python, PHP, Kubernetes Yaml dialect, or
any of the 20+ other supported languages
● We could have shown the same languages
supported similarly in Eclipse Che, Eclipse
Orion, NeoVim, Gnome-Builder or any of the
other supported tools
20. Limitations of LSP
● Focused on EDITION only. Missing other steps of dev
such as running, testing, debugging (a protocol-ish is
ongoing for debug)
● Misses some important operations
– Type hierarchy
– Refactorings
● Syntax highlighting not part of the protocol (but well
covered by TextMate grammars)
● Composition of LSP: how to chain them? Do multiple LS
on the same file complete one and other or conflict?
21. (Desired) Future of LSP
● Support for more typical edition actions (such
as refactorings or type hierarchy)
● Adoption of the Debug Server Protocol
(including support for Run and Tests)
22. Join the LSP game!
● https://github.com/Microsoft/language-server-protocol
– Contribute to specification
– Contribute by listing your support for a language or a tool
● Eclipse LSP4J: Contribute to Java bindings for LSP
● Eclipse LSP4E: Contribute to Eclipse IDE support for LSP
● Eclipse Che supports LSP
● Eclipse Orion supports LSP
● Other edition time technologies: consider adopting the
protocol for wider consumption