I'm on Windows 64 bits and I try to consume JSON server but without success:

• I have compiled https://github.com/Microsoft/vscode/tree/master/extensions/json/server to generate out/jsonServerMain.js
• I have customized the VSCode-JSON launch with my node + out/jsonServerMain.js

When I hover, open completion, etc teh launch starts but the "initialize" is never done. It seems that the server jsonServerMain don't give me any response.

Could you please store the jsonServerMain + node_modules dependencies in order to I check my problem comes from this server. More it will be more easy for other people who wish play with your work.

Thanks!

Like charp, it should be very nice to have syntax coloring for CSS.

If you wish I could try to do a PR.

Seems like a de-facto (non defined in protocol) convention is that the {{}} strings are placeholders for the cursor(s) after a completion. the Eclipse integration should support this.

See also microsoft/language-server-protocol#82

All symbols are listed as same level. The tree misses parency/hierarchy which is provided by Symbols.

You should use NLS instead of using String. I suppose that it was not your priority when you have started the project, but IMHO if you do not that now, you will do never (I know it's a boring job).

Connection with a language server is asynchronous. However, in most cases, the operations happen in the UI Thread and wait (with timeout) for the Language Server to respond. This freezes the UI.
We should investigate opportunity to introduce better support for asynchronous operations in the supported operations.

This is caused by TypeFox/ls-api#23

org.eclipse.languageserver should be spliited into several plugins:

• org.eclipse.languageserver.core
• org.eclipse.languageserver.ui
• org.eclipse.languageserver.csharp.core
• org.eclipse.languageserver.csharp.ui
• org.eclipse.languageserver.json.core
• org.eclipse.languageserver.json.ui
• org.eclipse.languageserver.css.core
• org.eclipse.languageserver.css.ui

Some icons are still missing others do not fit with look and feel.

It seems that CSS server doesn't filter completion items by using current word. The LSContentAssistProcessor.toProposals should filter items.

It should be really fantastic to give the capability to debug a node language server like JSON, CSS which are written in TypeScript:

• you import JSON, CSS language server written in TypeScript in your workspace.
• you set the path of JSON, CSS language server in your launch to your workspace project.
• you set a breakpoint for instance in the connection.onCompletion(textDocumentPosition => {

After that, you open a JSON file and you open completion. The JSON server is started in debug mode and it stops process to your breakpoint.

I have implemented this idea inside tern.java: you can debug your tern plugin written in JavaScript with any debugger (JSDT, Webclipse, Nodeclipse) and it provides a very cool mean to develop tern plugins.

In this issue we wish to debug TypeScript. typescript.java (based on JSDT) provides the capability to set breakpoints. Today you can debug TypeScript with Webclipse debugger (see angelozerr/typescript.java#2), but once https://bugs.eclipse.org/bugs/show_bug.cgi?id=487465 will be fixed, we could debug TypeScript with JSDT.

To support any debugger, we just need to delegate VSCode-JSON launch to a custom launch (not Program launch) to start nodejs in debug mode and initialize some info.

Once TypeScript language server will be implemented in this project we could even use the Generic Editor (with TypeScript) to support debugging.

I think "Debugging support for node langauge server inside Eclipse" could promote the use of this project to develop language server.

If you have not Eclipse WTP which defines content types org.eclipse.wst.jsdt.core.jsonSource and org.eclipse.wst.css.core.csssource, the JSON/CSS Editor with Generic Editor doesn't work because thoses content type are not defined.

Perhaps a solution is to define again org.eclipse.wst.jsdt.core.jsonSource

<content-type
        base-type="org.eclipse.core.runtime.text"
        file-extensions="json"
        id="org.eclipse.wst.jsdt.core.jsonSource"
        name="JSON"
        priority="normal">            
  </content-type>

Or working with a new content type org.eclipse.languageserver.languages.json which extends org.eclipse.wst.jsdt.core.jsonSource

<content-type
        base-type="org.eclipse.wst.jsdt.core.jsonSource"
        file-extensions="json"
        id="org.eclipse.languageserver.languages.json"
        name="JSON"
        priority="normal">            
  </content-type>

I don't what is the better clean mean. I post just some ideas without testing.

The current implementation assumes all operations are availablw and request them to LS anyway. We should rather check the result of the initialization to decide whether to make feature enabled in Eclipse and whether to perform the request.

Problem decorators should be shown on related symbols in outline (we can probably just check whether marker position in included in the symbol text area).

It should be very good to highlight completion items according current word (like Recommanders). I have already done that for typescript.java

If you are interested, I could do a PR.

Today, nodejs path is hard coded. It should be better to initialize nodejs path according teh OS

• try to find nodejs path in the known directory according the OS (ex :C:/Program Files/nodejs/node.exe for Windows, /usr/local/bin/node for linux)
• if not found, try to retrieve node inside PATH env.

In other words:

• create a org.eclipse.languageserver.util.NodejsHelper class
• provide a NodejsHelper#getNodejsPath() which retrieve node path.

I have already done that for tern.java and typescript.java. If you are interesed, I could do a PR.

See https://github.com/Microsoft/vscode-debugadapter-node and https://github.com/Microsoft/vscode-debugadapter-node/wiki/VS-Code-Debug-Protocol-Implementations

Take a simple sample:

• create a not valid test.json (outside Eclipse) with this content:

{

• copy/paste test.json in your Eclipse workspace.

Open test.json, the errors doesn't appear.

@mickaelistria you've made some calls for contributions so I'd like to leave my thoughts on that, from my part.

My initial impression of eclipse-language-service is that, of that the things that it does (or aims to do) that are of interest to me, there is a lot of overlap in scope with https://github.com/bruno-medeiros/MelnormeEclipse. But in that regard MelnormeEclipse is ahead in terms of functionality already implemented. (mostly UI boilerplate/widgets and a miscellanea of helpers and Eclipse integration code for basic functionality like hover, find-def, code completion, etc.)

This means that most contributions that I could make to eclipse-language-service would be taking code from MelnormeEclipse and applying it to ELS (see for example #14 (comment) ). The thing is, I would only be interested in doing that if the contributed code can still make full use of the utility classes and common components that MelnormeEclipse uses.

MelnormeEclipse is heavily refactored into common utlility code, and in many cases eschews traditional Eclipse idioms. For example, it doesn't normally use CoreException, but instead https://github.com/bruno-medeiros/MelnormeEclipse/blob/master/melnorme_util/src/melnorme/utilbox/core/CommonException.java , which is similar to CoreException except it's in a bundle that does not depend on OSGi (or anything else), plus it has a few minor API constraints (like, a message is required).

Another example is the concurrency utils (https://github.com/bruno-medeiros/MelnormeEclipse/tree/master/melnorme_util/src/melnorme/utilbox/concurrency) which do severaly things, but the main one is that they wrap the standard Java Future API with one that is more type-safe (or specific) with regards to exceptions. I'd want to use that if working against LSP4J code for example, which is heavily based on futures.

There are many other examples of utility code like that.

If i was to contribute MelnormeEclipse code to ELS without being able to use that common code, in most cases it would have to be modified heavily, which not only would mean more work, but IMO it would make the code worse. So generally speaking it's not something I would be interested in doing. (unless someone pays me 😆, that's a different story...)

So the question here is, how willing would you be to accept such common code in ELS. At the very mimimum I'd want the melnorme_util bundle, but even just that might not be enough as there is also a lot of common code in the other 3 bundles (tooling, ide.core, ide.ui). But I imagine quite a few things there (like this core Melnorme design principle) would look very alien to Eclipse developers, and even Java developers in general.

Note: It's not something l'm looking for an answer right now, as in any case I'm not doing any Eclipse LSP related work at the moment: I'm busy working on the Rust side of things. But I wanted to explain what is for me, eventually, an obstacle to contributing. Especially as there isn't much at the moment that ELS has to offer to MelnormeEclipse - the LSP4J-Eclipse integration is the main thing - but that seems fairly simple once one already has LSP4J itself, and UI boilerplate. Things would get more interesting if/once ELS had support for language functionality that MelnormeEclipse currently doesn't, like #11 or #56 , or find-references, etc.

Another question/issue for me is, how commited are you (and/or your employer) to developing ELS to maturity and beyond? Are there plans to mature ELS, sustain it and keep it up to date? Or is it gonna wither like DLTK without bearing much fruition? This is likely a question that you can't give a concrete answer to, I understand, but it's another concern of mine. (MelnormeEclipse was a user of DLTK in its early stages, but it was disappointing to see that DLTK stagnated and didn't go anywhere.)

Add support for refactorings coming from a language server into IDE Refactoring menu.

So, I can build eclipse-language-service from Maven fine, but now I wanted to try it out, running hosted from the Eclipse IDE, for which I need a Target Platform. Is there an easy way to set this up? I know the ls-api dependencies are in repository\target\repository, but I couldn't figure out which p2 repo contains org.eclipse.json, neither http://download.eclipse.org/releases/neon nor the latest Orbit repository seems to have it.

Today if you have not nodejs installed you cannot consume JSON, CSS VSCode language server. I remember that I had the same problem with tern.java and @maxandersen suggested me to provide an embed nodejs in order to avoid installing nodejs. The use of nodejs must be transparent for the final user.

I think more and more that nodejs support should be provided by Eclipse IDE:

• an UI preferences to customize the installed nodejs path
• an UI preferences to select an embed nodejs

This preferences could be used after by any plugin like tern.java, typescript.java, etc

If you are interesed, I could try to do a PR.

Maybe it would be more optimal to have separate ILightweightLabelDecorator for problems decoration?

LaunchConfigurationStreamProvider#getOutputStream redefine class accessible to call getSystemProcess:

// TODO: Ugly hack, find something better to retrieve stream!
Method systemProcessGetter = RuntimeProcess.class.getDeclaredMethod("getSystemProcess"); //$NON-NLS-1$
systemProcessGetter.setAccessible(true);
Process systemProcess = (Process)systemProcessGetter.invoke(process);
this.outputStream = systemProcess.getOutputStream();

A clean solution is to do define a org.eclipse.debug.core.processFactories and do like https://github.com/JPMoresmau/eclipsefp/search?utf8=%E2%9C%93&q=REPLProcessFactory to extends RuntimeProcess and set as public the getSystemProcess like https://github.com/JPMoresmau/eclipsefp/blob/master/net.sf.eclipsefp.haskell.debug.core/src/net/sf/eclipsefp/haskell/debug/core/internal/launch/REPLProcessFactory.java#L45

Provide an embed JSON server, CSS server, etc in order to avoid to the user to install VSCode, JSON, etc

Like in title.

Extenders should be provided an extension point to add support for new servers for a given content-type.

@mickaelistria pay attention with my PR #30

It seems that some language server like JSON, CSS doesn't support incremental synch (it's stange, with my test it worked).

In other words we need to sync the full document for JSON, CSS because the server returns TextDocumentSyncKind#Full:

/**
 * Defines how the host (editor) should sync
 * document changes to the language server.
 */
export declare enum TextDocumentSyncKind {
    /**
     * Documents should not be synced at all.
     */
    None = 0,
    /**
     * Documents are synced by always sending the full content
     * of the document.
     */
    Full = 1,
    /**
     * Documents are synced by sending the full content on open.
     * After that only incremental updates to the document are
     * send.
     */
    Incremental = 2,
}

We need to check the return of getServerCapabilities().getTextDocumentSync() to know if sync must be done with incremental mean (my PR) or full mean (the old code).

Sorry for my mistake -(

If you have not time, I will try to do a PR.

Support open symbols

When doing Ctrl+Click on some method or value to jump to definition, the cusrsor should be a hand instead of a regular text cursor.

Like charp, it should be very nice to have syntax coloring for JSON.

If you wish I could try to do a PR.

Code lens are a bit like refactorings and could be added on context menus like refactorings or quick fix.

Very often I have NullPointerException (see stacktrace). I don't know why and I'm not sure how to fix this. This particular stacktrace was thrown when I tried to select problem in Problems view.

I'm testing this LSP client with php-language-server and maybe I integrate something incorrectly.

!ENTRY org.eclipse.jface 4 2 2016-10-31 12:36:51.693
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".
!STACK 0
java.lang.NullPointerException
	at org.eclipse.languageserver.LanguageServiceAccessor.getLSWrapper(LanguageServiceAccessor.java:201)
	at org.eclipse.languageserver.LanguageServiceAccessor.getLanguageServer(LanguageServiceAccessor.java:175)
	at org.eclipse.languageserver.operations.codeactions.LSPCodeActionMarkerResolution.hasResolutions(LSPCodeActionMarkerResolution.java:96)
	at org.eclipse.ui.internal.ide.registry.MarkerHelpRegistry.hasResolution(MarkerHelpRegistry.java:182)
	at org.eclipse.ui.internal.ide.registry.MarkerHelpRegistry.hasResolutions(MarkerHelpRegistry.java:151)
	at org.eclipse.ui.internal.views.markers.QuickFixPropertyTester.test(QuickFixPropertyTester.java:37)

I have the NPE when JSON language server is initialized:

java.lang.NullPointerException
    at org.eclipse.languageserver.LanguageServiceAccessor.getLSWrapper(LanguageServiceAccessor.java:212)
    at org.eclipse.languageserver.LanguageServiceAccessor.getLanguageServer(LanguageServiceAccessor.java:170)
    at org.eclipse.languageserver.LanguageServiceAccessor.getLSPDocumentInfoFor(LanguageServiceAccessor.java:133)
    at org.eclipse.languageserver.operations.completion.LSContentAssistProcessor.computeCompletionProposals(LSContentAssistProcessor.java:41)
    at org.eclipse.ui.genericeditor.ContentAssistProcessorRegistry$ContentAssistProcessorExtension.computeCompletionProposals(ContentAssistProcessorRegistry.java:83)
    at org.eclipse.ui.genericeditor.CompositeContentAssistProcessor.computeCompletionProposals(CompositeContentAssistProcessor.java:35)

After debugging, it seems the problem is because ServerCapabilities#isCodeActionProvider return null (the JSON server return noen value for that) and NPE occurs when you do request.test(wrapper).

To fix my problem I have cathed this NPE but I'm not sure that it's a clean mean. @mickaelistria have you the same problem than me?

We should consider using launch configurations (external ones most likely) to start language servers. That would allow end-users to tweak some settings if necessary (think about the LD_LIBRARY_PATH for OmniSharp/dotnet on Fedora 24.

Code lens are a bit like refactorings and could be added on context menus like refactorings or quick fix.

As you type validation should use annotation instead of marker with IAnnotaionModel.

Outline should use a FilteredTree to easily navigate in symbols.

Users should be provided a wat to add support for a new language server. Defining a language server could be done using suggestion in #2 then users just associate a format/content-type with a Launch.

PHP for instance already has 2 LS, each one with some limitation. It would be goid to allow a content-type to consume multiple LS and if an operation isn't available in the first one, try others.

See microsoft/language-server-protocol@e1e5950
cc @mniewrzal

This is caused by TypeFox/ls-api#43

I have NPE in outline for JSON file:

{
	"test" : 1,
	"aaaa" : 1
}

Stacktrace:

!ENTRY org.eclipse.ui.navigator 4 2 2016-11-07 10:31:44.985
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.navigator".
!STACK 0
java.lang.NullPointerException
	at org.eclipse.languageserver.outline.LSSymbolsContentProvider.getChildren(LSSymbolsContentProvider.java:85)
	at org.eclipse.languageserver.outline.LSSymbolsContentProvider.hasChildren(LSSymbolsContentProvider.java:116)
	at org.eclipse.ui.internal.navigator.extensions.SafeDelegateTreeContentProvider.hasChildren(SafeDelegateTreeContentProvider.java:112)
	at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.callNormalHasChildren(NavigatorContentServiceContentProvider.java:444)
	at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.access$4(NavigatorContentServiceContentProvider.java:439)
	at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider$3.run(NavigatorContentServiceContentProvider.java:407)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.hasChildren(NavigatorContentServiceContentProvider.java:392)
	at org.eclipse.ui.internal.navigator.NavigatorContentServiceContentProvider.hasChildren(NavigatorContentServiceContentProvider.java:436)

At the moment, the implementation supports a language server per project, via ProjectSpecificLanguageServerWrapper. I wonder what are your thoughts about how it would work if we would want to use one server per workspace.

The simple solution would be to initialize its root with the workspace location, but projects need not be physically placed in the workspace (and also there are things like linked resources) and I'm not sure if that will work well. On the other hand, if the DidChangeWatchedFiles method is called by an Eclipse resource change watcher, then it might not be a problem.

When the VSCode-JSONlaunch is started it saved dirty editors. It can be strange if you are editing a txt file for instance and you open a JSON file and you open completion.

This behaviour is because of https://github.com/eclipse/eclipse.platform.debug/blob/master/org.eclipse.debug.core/core/org/eclipse/debug/core/model/LaunchConfigurationDelegate.java#L255

You can disable this behaviour with Save required dirty editors before launching from Preferences > Run/Debug > Launching, but I think it's shame.

I don't know how to disable Save required dirty editors before launching for a specific launch (i sit possible?) Perhaps a solution is to define a LSConfigurationDelegate which extends saveBeforeLaunch to avoid saving dirty editors.

Use ServerCapabilities#getCompletionProvider#getCompletionOptions#getTriggerCharacters to initialize completion processor to support triggers chars.

Today you are using Program launch, but I find it's not a clean mean. I think you should provide a new "Language Server launch" which call the "Program" launch (without saving it).

A "Language Server launch" will give you several benefit like provide a custom UI preferences:

• the node path (or an embed nodejs)
• a text with Browse button to select the JSON, CSS etc server.

The JSDT project follows this idea for npm, grunt, etc. It uses https://git.eclipse.org/c/jsdt/webtools.jsdt.git/tree/nodejs/org.eclipse.wst.jsdt.js.cli/src/org/eclipse/wst/jsdt/js/cli/core/CLI.java

The LSP-based outline misses the "Link with editor" feature.

Several bug reports were caused by NPE. We should leverage null-check analysis to avoid such basic bugs.