What Vim client should we recommend?

[olafurpg]

Currently, we recommend vim-lsc on our website https://scalameta.org/metals/docs/editors/vim.html I've been very happy with vim-lsc so far

• very simple installation, it just works with minor config changes
• window/showMessageRequest works for build import
• multiline diagnostics can be rendered on-demand

The vim-lsc maintainer has also been super nice and helpful in fixing blocking issues.

However, vim-lsc is missing several LSP features that Metals currently implements:

• $/cancelRequest: cancellation of outdated requests, this is tricky to implement client side but quite necessary to get good performance with the presentation compiler. Without cancellation you easily risk queuing up a lot of redundant completions.
• completionItem/resolve: lazy population of completion documentation and Java method signatures (without it you see signatures like substring(x$1: Int))
• textDocument/completion: Metals uses snippet format to insert the cursor inside parentheses and also additionalTextEdit which is needed for local imports
• textDocument/formatting: our Scalafmt integration
• textDocument/foldingRange

There is another vim client called coc.nvim that already implements almost all of LSP judging by https://github.com/neoclide/coc.nvim/wiki/Language-servers. I got coc.nvim working with vim 8.1 (neovim is not needed) and I really like the experience. However, coc.nvim has a more complicated installation process (requires npm). The coc.nvim project has moved very fast in the recent weeks, which I think is great, but also means it's maybe been less stable

My current inclination is to update our website to recommend coc.nvim because I'm afraid I personally don't have the time to contribute the missing features to vim-lsc (I don't use vim much these days, I did before).

Any thoughts?

See related comments from @ceedubs (https://github.com/scalameta/metals/issues/598#issuecomment-482149833) and @gvolpe (https://github.com/scalameta/metals/issues/598#issuecomment-482117958)

[gvolpe]

Thanks for writing this up @olafurpg . I hope next week I can give coc.vim a try once again with the latest metals and report back how it was.

The reason I haven't used it so far is that I don't really need all the features it supports because it also comes with a cost (uses much more resources) and it's one of the main reasons I just use neo-vim for Scala and Haskell development because it's just works and it's very lightweight.

I don't want to promise much because I'm moving to a different country next week but hopefully I can find the time to give it a try and at least report what works and what doesn't for me for the greater good.

I love metals :heart: , keep it up :muscle:

[ceedubs]

I found a Nix derivation that someone has posted online for coc.nvim, which was my holdup in trying it out. Hopefully within the next week I'll get a chance to try that out and can report my findings.

[GordianDziwis]

I worked with vim-lsp, vim-lsc, LanguageClient-neovim and coc-vim extensively. And in my humble opinion coc-vim is the best. It is very fast, works out of the box, quite free of bugs, integrates well with snippet engines and has sane configuration defaults. And it is a completion framework and language client in one plugin, which balances the yarn and node dependencies.

[olafurpg]

Thanks for the feedback everybody! My inclination is to recommend coc.nvim on the website since it's the most comprehensive implementation of LSP among the Vim clients. In #655 I updated the Vim page to at least mention that Metals works with most clients.

If someone wants to contribute, I would greatly appreciate a PR updating the Vim page explaining the steps to use Metals with coc.nvim. I would like to explain all the installation steps on our website even if the coc.nvim docs already do a great job of explaining how to register custom language servers. Ideally, the steps on the Metals website should explicitly list all requirements (vim version, Java version, ...) and assume minimal knowledge of Vim.

[ceedubs]

FWIW this Nix derivation for coc.nvim works for me, and so far (an hour or so of use) coc-nvim with Metals is really good.

[rcarcasses]

@ceedubs can you please describe your setup? so far I have defined the custom language server in coc-settings.json as follows:

{
  ....
  "languageserver": {
    "scalametals": {
      "command": "metals-vim",
      "trace.server": "verbose",
      "filetypes": ["scala"]
    }
  }
}

I do get code navigation among other features, pretty cool, but autocompletion (from the language server) doesn't work. From the logs it seems like there is indeed a proper communication between coc.nvim and metals, but completion request messages are not being sent.

I'm eager to see how this work!

[rcarcasses]

Ok, I found the problem with my setup: I was running an old version of metals (0.4.4), once I ran:

coursier bootstrap \
  --java-opt -XX:+UseG1GC \
  --java-opt -XX:+UseStringDeduplication  \
  --java-opt -Xss4m \
  --java-opt -Xms100m \
  --java-opt -Dmetals.client=vim-lsc \
  org.scalameta:metals_2.12:0.5.0+8-6693914e-SNAPSHOT \
  -r bintray:scalacenter/releases \
  -r sonatype:snapshots \
  -o /usr/local/bin/metals-vim -f

then coc-nvim indeed works with the previous settings. I would say that is very useful to do tail -f .metals/metals.log while coding, otherwise is hard to know what's going on.

Please keep going, this is awesome!

[z123]

Does anyone know how to make the sbt import working using coc-nvim?

[ceedubs]

@z123 make sure that you are using the most recent version of coc-nvim. I was having issues when I was using a slightly older version.

[gvolpe]

I've been playing a little bit with coc.vim and so far it works very well, though there are a few things that don't seem to work yet (maybe you guys are aware of these but just in case here they are):

• Jump to definition on extension methods (eg. can't jump to map in foo.map(_ + 1) having import cats.implicits._)
• See the available code actions when I get an error or a warning such as "unused imports" (I think this hasn't been implemented yet by metals?).
• I don't see the logs in the messages buffer at the bottom as I used to see with vim-lsc, I might be missing a configuration. Do others see the status like running bloop, etc?

The rest seems to works quite nice. I'll try to get it working with HIE as well to unify my lsp plugins.

[gabro]

Apart from the last point (which I don't know about), they are non vim-specific limitations of Metals.

Extensions methods generated by macros (simulacrum in this case) are still not supported (there's a ticket somewhere, I'll try to find it).

Code actions are also not supported yet, but in the specific case you can trigger completions on the unknown symbol to insert an import.

[gvolpe]

Thanks for confirming @gabro !

Code actions are also not supported yet, but in the specific case you can trigger completions on the unknown symbol to insert an import.

Yes, this is actually quite nice!

[gabro]

Extensions methods generated by macros (simulacrum in this case) are still not supported (there's a ticket somewhere, I'll try to find it).

Actually, I can't find a relevant ticket, maybe @olafurpg knows which one it is?

Repro:

import cats.effect._
import cats.implicits._
Resource.pure[IO, Int](1).map(_.toString) // can't jump to definition on `map` here

[gvolpe]

@olafurpg I got coc.vim working on my Haskell environment as well so I'm definitely in favour of recommend it as the default even though the requirements of installing node and yarn are a bit annoying.

Do you think we should leave vim-lsc as the default but also recommending coc.vim to those who want a richer experience? Or just add the docs for coc.vim and remove the details of vim-lsc completely? I like the first paragraph where all the LSP clients are mentioned.

I'm keen to work on a PR for this since all this knowledge is now fresh in my head :smile: , I've been installing everything from the scratch in a new laptop.

[olafurpg]

Great! I think it would be good to list the alternative clients and then show only the installation steps for coc.nvim, removing the vim-lsc parts.

[olafurpg]

Pending PR in #665 from @gvolpe updating the vim documentation to recommend coc.nvim, if anybody wants to try it out :)