Neovim plugin

[qu1ncyk]

Resolves #988.

This PR adds a Neovim plugin that makes it easy to use the Rascal LSP in Neovim. To make the LSP work in Neovim, this PR includes fixes for a NullPointerException.

NullPointerException stack trace

java.util.concurrent.CompletionException: java.lang.NullPointerException: Cannot invoke "org.eclipse.lsp4j.FileOperationsWorkspaceCapabilities.getDidCreate()" because the return value of "org.eclipse.lsp4j.WorkspaceClientCapabilities.getFileOperations()" is null
    at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)
    at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1770)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
    at java.base/java.lang.Thread.run(Thread.java:1583)
Caused by: java.lang.NullPointerException: Cannot invoke "org.eclipse.lsp4j.FileOperationsWorkspaceCapabilities.getDidCreate()" because the return value of "org.eclipse.lsp4j.WorkspaceClientCapabilities.getFileOperations()" is null
    at org.rascalmpl.vscode.lsp.rascal.RascalWorkspaceService.initialize(RascalWorkspaceService.java:61)
    at org.rascalmpl.vscode.lsp.BaseLanguageServer$ActualLanguageServer.lambda$initialize$4(BaseLanguageServer.java:260)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768)
    ... 3 more

To be honest, I'm not sure what getDidCreate, getDidRename and getDidDelete do and whether it is necessary to invoke getFileOperations 3 times, but at least the error is gone.

This plugin only adds support for the Rascal LSP, not for the parametric LSP.

[jurgenvinju]

Interesting! Thanks for doing this. Is there an easy way to include terminal support? Like in a split screen?

[qu1ncyk]

I added a command :RascalTerminal, which opens the Rascal REPL in a new terminal window inside Neovim. By default, it uses the built-in :terminal, but this can be configured to use a third-party plugin that provides a more user-friendly terminal, such as toggleterm.nvim.

[DavyLandman]

Hi @qu1ncyk

Thanks for your work in this PR.

1. Could you review & sign our CLA
2. Can you open a separate PR with the bugfix? that way we can make sure that gets released with the next release
3. Can we have some kind of tests for the neovim plugin? so we know if something breaks?

[qu1ncyk]

Hi, thanks for reviewing. I signed the CLA and opened a PR with just the bugfix. I'll look into testing.

[qu1ncyk]

Hi, I added tests for the plugin.

[jurgenvinju]

Cool stuff. We've been rather busy with releases and fixes for clients. But I see definitely a future for this plugin. How are neovim plugins distributed/made available to the community typically?

[qu1ncyk]

Well, things are messier than in VSCode I believe...

Neovim plugins are usually distributed via Git and sometimes via LuaRocks. Users can then use a plugin manager to download plugins by configuring a list of plugins. The most popular plugin manager is lazy.nvim. Others include mini.deps, the recently added built-in one, packer.nvim (used to be popular, but is now unmaintained) and vim-plug (made for Vim, but also works in Neovim).

Plugins can include LSP configurations that tell Neovim which binary to execute to start it by including an lsp directory. LSP configurations are usually distributed via the nvim-lspconfig plugin. Configurations from nvim-lspconfig use the built-in Neovim LSP client and cannot add features that LSP doesn't support. There are also language specific plugins that build on top of the LSP and add features that cannot be implemented using pure LSP, such as rustaceanvim, flutter-tools.nvim and roslyn.nvim.

The LSP configuration does not include the LSP itself, which usually has to be installed separately. I personally like to install LSPs using my system package manager (Nix). This search query on Repology shows a list of language servers that are available on various package repositories. A more popular approach in the community is to use the mason.nvim plugin to handle the installation of language servers. This plugin acts as a package manager that downloads language servers from mason-registry. At the moment, the plugin in this PR uses a build hook that compiles the LSP to a JAR for simplicity.

Currently, the plugin is in a directory, but Neovim/plugin managers by default assume that a plugin is in the root directory of the repo. Unison and onehalf are also like this. To tell Neovim to use the subdirectory as a plugin path, the runtimepath (rtp) needs to be updated to include this subdirectory. vim-plug supports this via the rtp option, which automatically sets the runtimepath to the subdirectory. lazy.nvim explicitly does not support this and requires users to update the runtimepath manually. I included this configuration in the Readme for the plugin. If this manual configuration is unwanted, the plugin can be put into its own repo.