Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support more language client implementations? #5

Closed
cannorin opened this issue Jul 17, 2019 · 13 comments
Closed

Support more language client implementations? #5

cannorin opened this issue Jul 17, 2019 · 13 comments
Labels
enhancement New feature or request

Comments

@cannorin
Copy link
Member

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):

Also, Neovim seems to be going to support LSP themselves: neovim/neovim#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!

@cannorin cannorin added enhancement New feature or request help wanted Extra attention is needed labels Jul 17, 2019
@scitesy
Copy link

scitesy commented Jul 17, 2019

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
Copy link
Member Author

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

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

@cannorin cannorin removed the help wanted Extra attention is needed label Jul 18, 2019
@Krzysztof-Cieslak
Copy link
Member

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
Copy link

tjm00 commented Oct 1, 2019

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

@cannorin
Copy link
Member Author

cannorin commented Oct 1, 2019

@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 dense-analysis/ale#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
Copy link

Parasrah commented Dec 6, 2019

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
Copy link
Member Author

cannorin commented Dec 7, 2019

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
Copy link

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
Copy link

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
Copy link
Member Author

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

@cannorin
Copy link
Member Author

We currently have a problem with the latest LS-neovim (#22) so I'm willing to support the built-in client.

@PhilT
Copy link

PhilT commented Mar 27, 2020

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
Copy link
Member Author

cannorin commented Sep 2, 2022

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. 🥲

@cannorin cannorin closed this as completed Sep 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants