docs: Add example for custom initialization options #307

[dongwa]

Purpose

Resolves #307

Goals

Just add some example for custom initialization options

[CLAassistant]

All committers have signed the CLA.

[payne911]

This seems to only provide the ability to assign a value for initializationOptions.

I think the library needs to instead provide a way to set the value of any field in this InitializeParams class.

Unfortunately, right now it seems like the only way to achieve that is by overriding LanguageServerWrapper#start() to be able to rework LanguageServerWrapper#getInitParams() (because that method is private).

[dongwa]

Yes, it only handles InitializationOptions, not InitializeParams. You would be better off opening another issue or pull request to address your question.

[NipunaRanasinghe]

Yes, it only handles InitializationOptions, not InitializeParams. You would be better off opening another issue or pull request to address your question.

I feel like having to create your own process builder just to pass InitializationOptions might not be a good design. Probably we can expose APIs from the LanguageServerDefinition to set both InitializationOptions and InitializeParams.

@dongwa @payne911 Any thoughts?

[dongwa]

Yes, it only handles InitializationOptions, not InitializeParams. You would be better off opening another issue or pull request to address your question.

I feel like having to create your own process builder just to pass InitializationOptions might not be a good design. Probably we can expose APIs from the LanguageServerDefinition to set both InitializationOptions and InitializeParams.

@dongwa @payne911 Any thoughts?

Yes, if LanguageServerDefinition has an API to set InitializationOptions and InitializeParams, I think it would be better. I am glad to help, but it would not be easy. We need a server to test.

[payne911]

What I've tried with the current code

Nothing worked, unfortunately. :(

Nonetheless, I'm listing my attempts below in case I'm simply not doing it properly.

CustomServerWrapper to override start()

I tried to figure out how to provide my own ServerWrapper via the ExtensionManager, but it seems like that's not possible.

Override LanguageServer#initialize

Then instead in my custom RequestManager (which is registered via my ExtensionManager) I tried:

override fun initialize(params: InitializeParams): CompletableFuture<InitializeResult> {
  // do as I wish to modify those params
  return super.initialize(params)
}

... but somehow I can't get this to work. (Yet I do have other methods which I've successfully overridden in my Request Manager.)
Shouldn't the above effectively allow us to "post-process" the InitializeParams as we wish before the initialize method request is sent to the server? The relevant code pointer:

lsp4intellij/src/main/java/org/wso2/lsp4intellij/client/languageserver/wrapper/LanguageServerWrapper.java

Line 533 in d0ca56b

initializeFuture = languageServer.initialize(initParams).thenApply(res -> {

---

Proposition

@NipunaRanasinghe I think you are right: providing a method like customizeInitializeParams(initParams: InitializeParams) in the LanguageServerDefinition would be good enough:

    public void customizeInitializeParams(InitializeParams params) {
        return;
    }

    private InitializeParams getInitParams() {
        // same stuff before
        serverDefinition.customizeInitializeParams(initParams); // this gets added
        return initParams;
    }

People could override this new method and add on top of the pre-processing that this library already does. This way, it's easy to keep part of the automation we already benefit from, while also giving all the possible freedom to the library's users.

[payne911]

@NipunaRanasinghe see #311

[NipunaRanasinghe]

@dongwa Is it possible to update the PR with changes introduced by #311?

[dongwa]

@dongwa Is it possible to update the PR with changes introduced by #311?

ok, give me some times

[NipunaRanasinghe]

@dongwa Is it possible to update the PR with changes introduced by #311?

ok, give me some times

Great! thanks

[dongwa]

Okay, I have updated it. Please help me review it.
@NipunaRanasinghe @payne911

[payne911]

GitHub's code suggestion feature does not seem to play well with the markdown code notation. But you'll get the gist of it.

I believe a readme should be light: we should avoid showing lengthy examples. Minimal examples, with reference points is preferable. The JavaDoc provided by the library should be sufficient if users are trying to dig deeper for their understanding.

Also, let's avoid mentioning things that just got deprecated: let's lead users to use the more recent versions. This also has the benefit of decluttering the readme.