How to extend an existing language with an LSP server?

Documentation says:

If there is already a VS supported language service installed (for example, JavaScript), can I still install an LSP language server extension that offers additional features (such as linting)?

Yes, but […]

Can you explain how to do that? I’m precisely trying to provide diagnostics for JavaScript using an LSP server. So I followed the tutorial to create a vsix with a client implementing ILanguageClient. The only difference is that instead of

  [Export(typeof(ILanguageClient))]
  [ContentType("bar")]

I tried:

  [Export(typeof(ILanguageClient))]
  [ContentType("JavaScript")]

But then ActivateAsync is never called.

[gundermanc]

Is with LSP something like this is possible?

Hi @ivanjeremic, something like this is possible, but it may have unexpected implications, such as breaking mixed language scenarios (HTML in Razor, for example), I recommend validating your extension very very carefully.

There are three options for extending a language that already has an in-box language service:

Add another LSP Server

IMPORTANT: this sort of extensibility is not officially supported. Use at your own risk.

You can do this using the existing ILanguageClient sample project. The main change you need to make is to use the content type of the existing language, instead of inventing your own. Start with this project and then:

• Delete the content type definitions and extension mappings
• Change the ILanguageClient’s ContentType attribute to the content type of the inbox language. You can determine that by using https://marketplace.visualstudio.com/items?itemName=MadsKristensen.ExtensibilityMargin or checking ITextView.TextBuffer.ContentType under the debugger.

This should now make it so that your LSP server starts at the same time as the inbox language server or classic language service.

Note that not all features support working with multiple active language servers at the same time. You may have better luck using the in-process extensibility for such additive extensions.

Use in-process extensibility

See the samples in this repo, such as:

• https://github.com/microsoft/VSSDK-Extensibility-Samples/tree/master/AsyncQuickInfo
• https://github.com/microsoft/VSSDK-Extensibility-Samples/tree/master/Ook_Language_Integration
• https://github.com/microsoft/VSSDK-Extensibility-Samples/tree/master/LightBulb

The overwhelming majority of these extensibility points can be driven by multiple extensions at the same time. You will likely need to do the same reuse the existing content type trick above.

Replace an Inbox Language Service Entirely

IMPORTANT: this will supersede the language entirely, per @asklar’s ask, is quite involved, and may have unintended side effects.

• Implement an editor factory (see DemoProject.zip or this VSSDK sample project)
• Your editor factory must have a higher priority than the language you are trying to supersede and declare the extensions you want (‘idl’) so that you get called before it.

[ProvideEditorExtension(typeof(EditorFactory), ".idl", 42,
              ProjectGuid = "{A2FE74E1-B743-11d0-AE1A-00A0C90FFFC3}",
              TemplateDir = "Templates",
              NameResourceID = 106)]

• Your editor factory creates a regular VS code window in CreateEditorInstance(), much like Roslyn does in their editor factory. If you run into any issues, you can look at theirs for reference.
• Your editor factory sets the document’s content type to your custom content type (the one that descends from ‘code-remote-base’. This sets up the editor to open the document with your LSP server instead of C++.

        //******************************************************
        //* TODO: Replace with your LSP content type.
        //******************************************************
        private const string ContentTypeName = "text";

• Before returning your text view and document, disable automatic language service SID detection, which is the old, rather obscure mechanism by which C++ lights up today. Without this step, Editor auto-detects C++ as the content type for the file by looking at a map in the registry that indicates that IDL is handled by C++ LS.

                // Disable language service auto-detection before loading document data.
                // This prevents the C++ language service content type from being set.
                return userData.SetData(VSConstants.VsTextBufferUserDataGuid.VsBufferDetectLangSID_guid, false);

End to end demo project: DemoProject.zip

[LukaszMendakiewicz]

Thanks @asklar for a thorough write-up. I’m forwarding this to our Program Managers who can account for it in the feature planning.