Support changing language server parameters from third party plugins

[ddscharfe]

Use case: A vendor wants to customize the command which is executed to start clangd.

There is an extension point to add a ICLanguageServerProvider, but in order to still be able to use the preferences page, CdtCLanguageServerProvider would have to be public API.

[ruspl-afed]

The use case is clear. However, I'm not sure if CdtCLanguageServerProvider should be an API because of it. I would say vendor can override the default preference values.

[ghentschke]

Basically the DefaultCLanguageServerProvider represents a default clangd implementation and could be moved to org.eclipse.cdt.lsp.clangd.server as DefaultClangdLanguageServerProvider. The disadvantage of this move is, that vendors have a dependency on the org.eclipse.cdt.lsp.clangd bundle as well. My intention was that vendors should only need the org.eclipse.cdt.lsp bundle. But on the other hand, if a vendor wants to create its own clangd LS provider it makes sense to extend the DefaultClangdLanguageServerProvider. This package could be public API and can be extended by vendors.

So vendors who won't use clangd have to implement ICLanguageServerProvider. Clangd users could/should extend DefaultClangdLanguageServerProvider.

I would say vendor can override the default preference values.

Since the settings are tightly coupled to the clangd server provider, I would say it makes sense to make the CdtCLanguageServerProvider public API in the same org.eclipse.cdt.lsp.clangd.server package. This will prevent race conditions as well, when the vendor wants to override the default preferences (what is very likely).

Conclusion: I assume that most vendors would extend CdtCLanguageServerProvider and not DefaultClangdLanguageServerProvider. IMO it should therefor be public API.

[ruspl-afed]

This ticket is about extending (overriding) a list of commands. What else do we plan to open for extension?

[ghentschke]

This ticket is about extending (overriding) a list of commands.

That's right. The question for me here is how a vendor could achieve this without an API (Overriding createCommands). I don't see it yet.

What else do we plan to open for extension?

I don't know about anything else (yet) - May be when I'am implementing the extension.

[ddscharfe]

This ticket is about extending (overriding) a list of commands.

That's right. The question for me here is how a vendor could achieve this without an API (Overriding createCommands). I don't see it yet.

What else do we plan to open for extension?

I don't know about anything else (yet) - May be when I'am implementing the extension.

Instead of making the class public API we could provide an extension point, or a hook via dependency injection. This would make the surface of the API smaller. However it might be a little early for such things, as we are currently in a phase where the architecture is not complete yet. Maybe let's make CdtCLanguageServerProvider API, but flag it as provisional and decide what becomes stable API later?

[ghentschke]

I took a while, but I get it now what @ruspl-afed suggested. Just extend the DefaultCLanguageServerProvider and modify the preferences default settings in overwriting createCommands. Therfor prefercnes must be public API.... Just seen the new issue #83. Great!

[ruspl-afed]

Currently 3rd party bundle may replace preferences defaults, but we may want to allow vendor to do full replacement of ClangdConfiguration implementation (and its UI part).

[ghentschke]

I think the approach from @ruspl-afed mentioned here seems to be a good starting point:

For example, we can add "server id" metadata to both "provider" and "configuration" and then invoke ServiceCaller with specific filter argument. Or think about something else.

[ghentschke]

The properties and preference page (LspEditorPropertiesPage and LspEditorPreferencePage) should be hidden when the ClangdLanguageServerProvider is not used.