Don't automatically open noogle.dev urls provided by nixd

[Meallia]

Fixes #98

Recent nixd versions now provide a code action to open documentation for nixpkgs'lib function in noogle.dev.
Unfortunately, the LSP client implementation in jetbrain's IDE does not handle it nicely.
As described in the issue, whenever the cursor is on a symbol from lib.* and ANY key or mouse button is pressed, a new browser tab opens.

The LSP client ( the IDE ) receives the following codeAction from the LSP server ( nixd ):

kind: refactor
title: Open Noogle documentation for mkIf
data: {"noogleUrl": "https://noogle.dev/f/lib/mkIf"}

It then tries to build an Intention action ( The yellow light bulb ), to do that, it calls the server back to get the diff.
Instead of providing a diff, the LSP server replies with window/showDocument with the noogle URL as parameter.

Instead of calling the LSP server back and opening a new tab, the IDE will now display an intention to open the provided url.

I could not find a way to change the tooltip for the action.

Let me know if a checkbox in the LSP settings panel should be added.

Also converted the LspServerDescriptor code to kotlin since it was almost impossible to write this in java.

[JojOatXGME]

Thanks. Looks like a reasonable workaround.

I also checked the LSP documentation, and I honestly think that this is a bug in nixd. I think they misunderstood the specification. Here is the documentation for codeAction/resolve, the action which is sent from the IDE to the server when edit is missing:

The request is sent from the client to the server to resolve additional information for a given code action. This is usually used to compute the edit property of a code action to avoid its unnecessary computation during the textDocument/codeAction request.

I suspect nixd assumed that codeAction/resolve represents the execution of the action (i.e. resolving the code issue), but it is actually just a mechanism to enable lazy loading of the diff. VSCode probably just happens to not care about the diff before it is executing the action.

Unfortunately, I don't know if there is any other way how nixd could have implemented that feature. CodeAction also has a command field, but not sure how that works. I only scanned over the documentation.

PS: Regarding Kotlin...

Also converted the LspServerDescriptor code to kotlin since it was almost impossible to write this in java.

That seems like an overstatement. Java is verbose, but it is not that unusable. 😄 But I am fine with using Kotlin. I just don't like global non-private functions (i.e. functions outside of namespaces which can be associated with a file), and sometimes the habit of overusing extension functions for everything.^^

[Meallia]

Unfortunately, I don't know if there is any other way how nixd could have implemented that feature. CodeAction also has a command field, but not sure how that works. I only scanned over the documentation.

I tried to find a way to re-write the codeAction, but there is nothing is the spec to link to external documentation.

They could have used an action, but nothing is standard, each LSP plugin would have had to implement a hook to resolve it.

That seems like an overstatement. Java is verbose, but it is not that unusable. 😄 But I am fine with using Kotlin. I just don't like global non-private functions (i.e. functions outside of namespaces which can be associated with a file), and sometimes the habit of overusing extension functions for everything.^^

I trust you on that. 😄 I'm neither a java nor a kotlin dev, but I found myself fighting with java a lot when implementing this change.

[JojOatXGME]

FYI, I created an issue for nixd at nix-community/nixd#818.