×

Status message

This proposal has been approved and the Eclipse LSP4E project has been created.

Eclipse LSP4E

Basics
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project: 
Background: 

The Language Server Protocol is an open-source protocol to interact with a "language server", responsible of computing and suggestion edition assistance on request. The protocol is open at https://github.com/Microsoft/language-server-protocol. This protocol and language servers are meant to simplify the development of tools for a given language. The IDE or editor becomes a "front-end" for the language server. There are already language servers for multiple popular languages.

Typical operations of language servers are: error reporting, completion, documentation, get references...

Scope: 

The scope of the project is to provide integration of language servers conforming to the Language Server Protocol into the Eclipse IDE. It includes some APIs to turn language server protocol elements into Eclipse IDE concepts and a generic integration allowing to easily plug any language server to an Eclipse IDE instance without need to write Java code, either via a plugin associating a new language server, and by letting users manually bind language servers to their IDE.

Individual language servers (VSCode, OmniSharp...) and the necessary layers to actually run a language server (node.js...) are not in the scope of this project. The project aims to easily connect to those, not to ship them. Shipping individual language servers should be considered by project that specifically target tooling for this language.

Description: 

The project includes the necessary code to integrate any language server in the Eclipse IDE, interacting with the language server: it orchestrates the request to the language servers and presents the response in the usual IDE metaphors so users can manipulate them.
The default integration is to provide features into the Platform's Generic and Extensible editor, but some code may be used as API to let integration be done with other Eclipse-based editors.

Some examples of integration are:

  • Show errors from language server as problem markers in the Eclipse IDE
  • Show completion proposals from language server into the Eclipse IDE Generic Editor
  • Show documentation from language server as hover into Eclipse IDE
  • Jump to declaration in Eclipse IDE, relying on language server results
  • Find References in Eclipse IDE, relying on language server results
  • Rename elements according to langauge server proposal
  • View Symbols in Outline/Quick Outline
  • ... more of current LSP feature to integrate
  • ... more to come as language server protocol get enhanced

 

Why Here?: 

This project targets solely the Eclipse IDE. It is likely to provide a lot of value to easily add support for new languages into the Eclipse IDE. The Eclipse IDE can take a big advantage of such integration.

On the other hand, the project would benefit from being inside the Eclipse.org community by attracting more experienced Eclipse developers who're already contributing to some related projects.

The project heavily relies on Eclipse LSP4J project and on Eclipse Platform project (especially on the Generic and Extensible editor part).

Project Scheduling: 

To bootstrap good practices, the project will attempt a first incubation release as soon as it is provisioned at Eclipse.org.

Then the target is to have multiple incubation releases, about once a month if there have been changes, to include improvements, bugfixes and new features available in the language server protocol and the LSP4J project.

Then, if there are interesting language servers Eclipse IDE can ship by June 2017, the Eclipse LSP4E project would be released as 1.0.0 as part of the Oxygen release train. If no integration with a language server is immediatly profiting to the Eclipse IDE, the project will continue as incubation.

Future Work: 

Integrations with various languages servers will bring needs to support more Language Server Protocol features, and will bring some questions such as how to deal with multiple "competitive" language servers contributing to the same language.

It is also very likely that a similar protocol will be developed for debug and that several languages share a common interface to interact with debuggers. In such case, integration between the Eclipse IDE and such debug protocol could be added to this project.

Another step will be to consider development or adoption of a discovery of language servers.

People
Project Leads: 
Committers: 
Michał Niewrzał
Kaloyan Raev
Mentors: 
Interested Parties: 
  • Corporate:
  • Red Hat Inc.
  • TypeFox
  • Rogue Wave/Zend

Individuals:

  • Doug Schaefer
  • Pascal Rapicault
  • Yogesh Bitake
  • Lars Vogel
  • Marc-Andre Laperle

Related projects:

  • LSP4J committers
Source Code
Initial Contribution: 

The initial contrbution is a functional code, currently stored on GitHub, with active contributors: https://github.com/eclipselabs/eclipse-language-service .

The copyright mostly belongs to Red Hat Inc., contributions that were made by non-Red Hat contributors were done on files that show the Copyright and license headers, without any concern from contributors. So it's assumed that all contributors have contributed approving the EPL license.

Source Repository Type: 
Holger Schill's picture

Hi!

We (itemis) are highly interested in that project. Please add us to the list.

Thanks

Holger

Doug Schaefer's picture

Aside from the PMC question, I'm definitely interested. Need to figure out how C/C++ plays in this new world, both as a server of the LSP as well as a client using the fruits of this project. I've done some investigation into libclang and it looks promising as an indexer, LSP provider.

Mickael Istria's picture

Thanks for you interest. When you have a language server running, you can immediately try it with the GitHub code at https://github.com/eclipselabs/eclipse-language-service . Reporting feedback of a new language server would be welcome. At the moment, we're using GitHub issues, and we'll move to Bugzilla when project is provisioned.

Pascal Rapicault's picture

I'm interested.

Mickael Istria's picture

Thanks for you interest, You can already try this from https://github.com/eclipselabs/eclipse-language-service and start contributing there.

Yogesh Bitake's picture

Mickael ask via Twitter: You like #Eclipse IDE? you like the language server protocol? You'll love projects.eclipse.org/proposals/lsp4… ! Ping me if you want to be involved PING. I'm interested to get involved.
Mickael Istria's picture

Thanks for you interest, You can already try this from https://github.com/eclipselabs/eclipse-language-service and start contributing there.

Lars Vogel's picture

Mickael ask via Twitter: You like IDE? you like the language server protocol? You'll love ! Ping me if you want to be involved

 

PING. I'm interested to get involved.

Mickael Istria's picture

Thanks for you interest, You can already try this from https://github.com/eclipselabs/eclipse-language-service and start contributing there.

Doug Schaefer's picture

This project seems pretty fundamental to the future of the Eclipse IDE. Why isn't this project under the Tools project?

Mickael Istria's picture

The idea was to follow LSP4J and the JGit/EGit pattern (all in Technology).

I don't get what would be the gain/loss of Techonology vs Tools. I'm not opposed to suggest a move to Tools if it's clear there is something to win there that we can't have with Technology.

Doug Schaefer's picture

Technology was meant to be the home for projects no one else wanted or for experimental things. Tools was meant for, well, tools, or more specifically IDE things. We have discussed why EGit isn't a Tools project and aren't sure of the answer.

It's hard to say. I think there's a long standing need to revisit the role of these two top level projects. It should be more obvious than it is. And frankly both top level projects are too big and diverse to get anything meaningful done as a collection of related projects. So in the end, it doesn't really matter.