Add support for lexical syntax coloring

[svenefftinge]

I know lexical coloring is something that should be done on the client. However as this information is fully declarative (TextMate language grammars) we could serve the initial configuration from a language server instead of putting it into the extension json.

The reason is that I would like to define and package one language server and use it in many different editors as is. I.e. without the need to do some editor specific plumbing for every editor. Today only VSCode understands this protocol, but we should try to make it more widely used in order to leverage its full potential. I.e. we are working on a client for Che and on a server side implementation with Xtext.

For servers that only target vscode It could be simply ignored and turned off through the server capabilities.

[egamma]

The reason is that I would like to define and package one language server and use it in many different editors as is. I.e. without the need to do some editor specific plumbing for every editor.

It is not clear how this would work. Each editor has a different extension/plug-in layout on disk with different manifest files (just compare sublime and vscode), so I don't see a way for how to avoid some editor specific plumbing for a supported language.

[svenefftinge]

Yes, my suggestion is about streamlining that as well. I.e. if editors can get all the needed information from a language server, there is no need for different plug-in formats per editor. At least not for the 80% case. We could work on generic language server extensions per editor that can run cross-editor language server plug-ins.

If you want to build really shiny products, you might want to have more control over UI-stuff and build editor-specific extensions, but for many cases the services provided in this protocol could be sufficient if lexical coloring was included (and maybe an icon :-)).

[dbaeumer]

A solution I could think of is extending VSCode's language configuration API with a property that points to the TextMate grammar. Something like:

export interface TextMateGrammar {
    language: string;
    scopeName: string;
    path: string;
}

export interface LanguageConfiguration {
    ...
    textMateGrammars: TextMateGrammar[]
    ...
}

@jrieken @alexandrudima would that be possible

[egamma]

While this would be possible it is not clear much this really helps. The grammar need to exist statically inside the extension on the file system so that they it is discovered by the editor (configuration by conventions), see Sublime or Atom.

Grammars are only part of the extension/plugin configuration of the host/editors, there are also snippets and other configuration options like auto indents. All of them need to exist statically on the file system.

The language server should therefore focus on the server/language brain part on not on the 'host'/ extension mechanism specific configuration.

I therefore suggest to close this enhancement request.

[svenefftinge]

Why do they need to be served from the file system? It is not so important that the configuration is served from a server, but it would be cool to have a way to package language plugins that work in different editors as is. I am kind of after some standard plugin format for language support.

[egamma]

Why do they need to be served from the file system?

This is a design decision of the editor implementors. These days they prefer to use configuration by convention, so the fact that there is a grammar file inside an extension marks that the extension supports a particular language. Check out any Sublime language extension.

after some standard plugin format for language support.

I'm not opposed to the idea, but to me this is not in the scope of the language server protocol and this project. This should be a separate effort/project.

[svenefftinge]

I'm not opposed to the idea, but to me this is not in the scope of the language server protocol and this project. This should be a separate effort/project.

Ok, agreed.