Support more language client implementations?

[cannorin]

Although we currently use autozimu/LanguageClient-neovim for the LSP part, it is not the only lanuguage client implementation available for (neo)vim. Here is the list of them I can find (in no particular order):

• prabirshrestha/vim-lsp
• w0rp/ale
• natebosch/vim-lsc
• neoclide/coc.nvim

Also, Neovim seems to be going to support LSP themselves: https://github.com/neovim/neovim/pull/10222

I randomly picked autozimu/LanguageClient-neovim but everyone should have their own preferred and/or already installed LSP plugin. So I'm wondering if we should also support some of them (if not all of them).

Thoughts? We would love to hear your input!

[scitesy]

After looking at the options, I am happy with the current LanguageClient-neovim feature set. It is always nice to have options but I personally wouldn't incur the development/complexity/maintenance cost unless there is proven demand for one or more of the other options. I'd be very happy with one well maintained option:)

[cannorin]

Thanks @scitesy, we'll stick to LC-neovim for now.

I'll keep this issue open for future possible inputs.

[Krzysztof-Cieslak]

I know nothing about vim ecosystem so take whatever I say with huge pinch of salt... but if there is one thing I've learnt over all those years building developer tooling, it would be:

There is great value in providing well working opinionated solution

So, I'd recommend - first make sure that what we're delivering users by default is working really well, then potentially think about customizations and other clients... if and only if people actually ask for it. It may turn out people prefer to have well working client over their "ideal client" but not working as well with F# ;-)

[tjm00]

For what it's worth, I came here looking for ale support.

[cannorin]

@tjm00 Thanks for input! ALE seems to be the most popular among them (in terms of GitHub stars) and supporting it is definitely an option to consider. I didn't choose it at first because it is big, self-contained and complicated so that I felt overwhelmed to work with. However, I did a quick search and found out that adding custom language server should be relatively easy according to https://github.com/dense-analysis/ale/issues/2641 . I can't promise when but I'd like to work on ALE support once other tasks (such as FSI integration support) are done.

[Parasrah]

I'm just in the middle of making LC work for my workflow, but I typically use CoC.nvim heavily, and it's been gaining traction fairly quickly in the last year. I think a lot of people use ALE (myself included), but I think most people working in my domain (web) often use something else for their completion. Of course I completely understand if supporting ale is a bigger win for the plugin, and I don't see any reason I can't get ALE or LC working in parallel with CoC

[cannorin]

If I understand correctly, writing an extension for coc.nvim requires writing TypeScript, and typically done by porting an existing VSCode extension. That would incur a lot of work compared to supporting ALE, and this is why I'm hesitating to do.

[Parasrah]

That makes complete sense, and I think I've got a fairly good workflow going with both in parallel. As long as I can have ALE installed and still use LC for completion etc (I only use ale for linting) then I don't think the changes would impact me.

[Parasrah]

Might be worth potentially adding the build-in language client being offered in future versions of neovim to the list? I'm not sure how far along the ale implementation is, but having something officially supported by the core neovim team is a big win for me, and I'll likely be switching away from coc.nvim when I feel it's stable enough.

I would also be interested in helping out if that is a feature your team would like to add to the plugin

[cannorin]

yes, having neovim's built-in client supported would be a big deal.

[cannorin]

We currently have a problem with the latest LS-neovim (https://github.com/ionide/Ionide-vim/issues/22) so I'm willing to support the built-in client.

[PhilT]

Coc integration works with a bit of config although you can't have the Ionide-vim plugin enabled so it might not be fully featured.

I couldn't work out how to set the correct server command in LC neovim config on Windows so found a way to get Coc working.

Run :CocConfig and add:

  "fsharp": {
    "command": "dotnet",
    "args": ["<path to vim plugins>/Ionide-vim/fsac/fsautocomplete.dll", "--background-service-enabled"],
    "filetypes": ["fsharp"],
    "ignoredRootPaths": ["/","~"]
  }

[cannorin]

Closing this as we've been using neovim's built-in LSP client for a while.

• ALE and CoC were the only implementations people expressed their interest
• CoC uses a completely different architecture, so it would be difficult to maintain in this repo along with other implementations

So I will keep #18 open just in case someone gets interested. 🥲