-
-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
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:) |
Thanks @scitesy, we'll stick to LC-neovim for now. I'll keep this issue open for future possible inputs. |
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# ;-) |
For what it's worth, I came here looking for ale support. |
@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'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 |
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. |
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. |
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 I would also be interested in helping out if that is a feature your team would like to add to the plugin |
yes, having neovim's built-in client supported would be a big deal. |
We currently have a problem with the latest LS-neovim (#22) so I'm willing to support the built-in client. |
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
|
Closing this as we've been using neovim's built-in LSP client for a while.
So I will keep #18 open just in case someone gets interested. 🥲 |
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!
The text was updated successfully, but these errors were encountered: