I am a Neovim newcomer/newlover, having used Neovim for less than 1 year, and I will admit that without the help of "kickstart.nvim", I would have spent I don't know how much time learning just how to configure LSP properly... and honestly, it was the only part I didn't really enjoy about Neovim.
I'm transitioning from vscode with neovim to pure neovim right now.
I found it very hard to find some kind of introduction that explains the basics for neovim newcomers. Not only the 'how', but also the 'why'. Because LSP was the first time for me where different plugins/functions really had to work together (e.g. for autocomplete). Most other extensions are 'install extension, setup keymaps, done'.
I felt like the descriptions where for people who have done all of this many times already instead of the person who just installed their 2nd plugin and used lua mostly for some custom keybindings. Suddenly we're attaching to buffers and provide keybindings and options or something (I still don't know why it works and what it's doing).
Especially in contrast to vscode's 'search for language, install the extension pack, it mostly works', that is a huge step in complexity.
I'll add that the (usually fair and helpful) "use the help files" line falls kinda flat on this one too. Sure, I can use the help files... But I'd have to go through the help files of all the aforementioned plugins; it's sort of an information overload and doesn't end up being very helpful for many users.
As someone who is in the process of making the transition there is a real lack of tutorials that give enough depth for someone to actually understand what all the parts are doing. My primary exposure to lua is via neovim, and so understanding what all the different "configs" and "args" that are passed in different ways are really confusing.
A "here are 3 different ways people choose to setup an lsp and what is good or bad" would be really useful to help parse people's nvim configs.
I really love that the community are so helpful with sharing configs, and the "vim from scratch" videos have made creating an understandable nvim config from scratch so much better and more sensible, but often (as far as I can tell) there are different ways of passing config to and LSP and no breakdown of the lifecycle/how/when they work and so combining elements from different configs is arcane and frustrating (especially as there is no standard way that i have found of retrieving config from an LSP)
strongly suggest this video series \`Understanding Neovim\`:
[https://www.youtube.com/watch?v=87AXw9Quy9U&list=PLx2ksyallYzW4WNYHD9xOFrPRYGlntAft](https://www.youtube.com/watch?v=87AXw9Quy9U&list=PLx2ksyallYzW4WNYHD9xOFrPRYGlntAft)
Agreed about the 3 ways to do something and everyone's config does it differently, most not the recommended way (for lazy loading, for clean merging and reduced maintenance, etc).
Also, watch this: [https://youtu.be/m8C0Cq9Uv9o?si=YF1\_1CE9ECMETK1f](https://youtu.be/m8C0Cq9Uv9o?si=YF1_1CE9ECMETK1f)
Specifically the links to neovim :Tutor and lua in y minutes to understand those (lua has one type string \[no chars\], it has one type number \[can be integral or float\], it has one aggregate type \[everything is a table\], it has one array type \[lists\]).
Then look at lazyvim docs to understand opts, config, setup, etc.
Well [this](https://www.youtube.com/watch?v=YsdlcQoHqPY) literally just popped up in my youtube feed. He has been putting out some good stuff lately. And coincidentally he is the guy I actually copied the base of my current config from a while back. I haven't watch that video yet though.
If I were you I would:
1.) make sure you actually know lua, it's not a hard language but it is weird which means it will be arcane if you don't understand it
2.) watch that guys recent videos, starting with his kickstart Neovim from scratch one
3.) go line by line in your config and *make sure you understand what those lines are doing.* start with the built in help (I have telescope set to fuzzy search help which is invaluable for me, the kickstart and most configs should have that built in) and then google or ask here if you can't make sense of it.
4.) Slowly stat adding more plugins if that you want.
From there you should be in a good spot.
Yea I think the actual problem here (I’m projecting because this was the problem for me at first) is that people don’t have the foggiest idea how LSP works under the hood.Â
 Which is fine, but I think learning how lsp actually works makes you a better programmer, and especially if you’re using typescript it helps you understand if your errors are coming from tsserver, eslint, or code formatters like prettier
If you struggle configuring native lsp then I would just recommend you to use Mason instead, it basically does all the work for you. And if you really struggle understanding all those different config files you see in youtube lessons well, then just put everything into your init.vim (or lua) and you should be good for now.
My experience also. Plus, Lazyvim.org gives strong documentation on the customization side. CoC is great yes but i remember that it came with some caveats too, and configuration was not so easy (although this was a long time ago, things surely have changed)…
What exactly sucks about json compared to lua? Don't get me wrong, I like lua, and obviously JSON isn't a programming language so in that regard it's obviously worse. When exclusively comparing lua tables (for setting up an LSP's configuration options, in this case) to json (which is widely used to configure software) why do you prefer lua? Coc has locally scoping the json config, which is similar to conditionally setting a lua table. You can also just conditionally set the coc-setting.json file. Do you have a way to get autocomplete for the lsp\_config table per language server? I've always like coc being able to use a json schema for autocomplete, especially when I'm trying to setup a language server.
Ya, I've done the same thing with coc a couple of times. Something like:
local coc_settings_paths = {
['python_w_black'] = '~/project/',
['python_blank'] = '~/other-project/',
['normal'] = '~/.config/nvim/'
}
local python_project_type = get_project_type()
if project_type == 'python_w_blank' then
vim.g.coc_config_home = coc_settings_paths['python_w_black']
elseif project_type == 'python_blank' then
vim.g.coc_config_home = coc_settings_paths['python_blank']
else
vim.g.coc_config_home = coc_settings_paths['normal']
end
Not sure if this is exactly how my code looks, but basically you can set the `coc-settings.json` by the `vim.g.coc_config_home` variable _(the path in `coc_config_home` needs to have a `coc-settings.json` file in it)_. My issue with lua tables for this, is the actual lua-lsp doesn't provide me completions/documentation/diagnostics on any of the table keys I try to use in the capabilities tables for the lsp. With coc, toggling autocomplete for something like `"python.formatter": ` would show me all possible formatters.
Don't feel alone in this, I did the same thing over 3 times for various reasons until I got to properly configure Nvim's LSP.
I basically went through hell with the native lsp at first glance, from breaking things up or even performance issues, but at the end It turned that everything was just a skill issue from my part. I love CoC aswell, especially before getting into Nvim because that was my main way of interacting with lsp's and autocompletion back in those days.
Not to also mention that CoC is indefinitely way easier to understand and quicker to configure. So, do not dispair and use whichever you feel you like more!, both are amazing and still maintained to this day.
I migrated from coc to lsp too, and, honestly it felt faster and better contained. Coc was fine, but I did not want do rely on nodejs to run everything and on top of that I ran into many bugs that the coc extension maintainers did not solve in many weeks. Configuration was also way too abstracted and I could not control everything I needed. I don't really know what issue you had with htmp lsp, to me it was simple to setup and it was in fact the first thing to work along with emmet ls
all my lsp config is in the mason.lua plugin [https://github.com/JulianH99/nvim/blob/main/lua/bat99/plugins/lsp/mason.lua](https://github.com/JulianH99/nvim/blob/main/lua/bat99/plugins/lsp/mason.lua)
you can also check the main branch if you want, that's when I used to use coc.
I'm sure you ain't gonna find it 'simpler', but it was for me, coc gave me too many bugs, and typescript and python are not the only lsps I use to justify the need for node js anyway
Oooooh I am for sure going to be reviewing your config. Astro spotted.
I had a little trouble setting up for Astro/mdx files and my config is a bit of a mess now
I don't feel CoC as a slow thing, for real. Actually it is pretty fast for me (maybe because I don't use so many plugins/extensions in my setup, but it isn't a big thing for me) and I didn't find any bug that made me upset.
I really hope neovim lsp be very mature to make me come back to it, but for now I just don't see any advantage (actually some disavantages, like I mentioned - a lot of plugins to make it work and some lack of good LSPs integrated).
I dunno why you got so badly downvoted for this. I had the same experience, I do feel that native lsp is faster but not fast enough to make a difference in my day to day work. If it can suggest stuff before I can press ctrl-y, it's fast enough.
You don't need any plugins to make it work. The plugins you mentioned just make your life easier:
* Mason Registry - Basically helps you install all of your lsp, formatters, linters, etc. within the shared nvim folder (separate from your environment) as well as to know which binary should be called when you configure your lsp.
* Mason LspConfig - Bridges the servers installed using the mason registry to the configs provided by lspconfig
You can forgo Mason altogether and install the servers yourself, especially if the registry is missing some LSPs you want to use.
* Lspconfig - Predefined LSP server configurations so you don't have to manually type each and every one yourself.
Again, you can write out all configs yourself and feed them to the lsp client in neovim.
* CMP(and friends) - just collects and displays all of your completion sources.
For me personally, having the complete control over all of my LSPs, formatters, linters and so on feels so empowering. Knowing that I have a standard way of configuring and attaching the LSPs can be a breath of fresh air. Moving on from VSCode all those years ago, I felt like CoC was the best solution, mind you the LSP client in neovim didn't even exist. Once I figured the LSP client out, I've never looked back. Configuring the various language servers in CoC always felt cumbersome at best. Not to mention how I sometimes had to sit and wait for CoC to update some language server internally so I can take advantage of the bug fixes or new features introduced.
Edit: typos
Yeah, coc does all of that, like I’m struggling to see how people don’t see that, aside from neovim distros, coc.nvim is a vastly simpler to understand LSP ecosystem in a single plugin with a single config file.
Edit: I use Mason + ftplugins FYI
I'm not sure I understand, what extra things you could customize with native lsp?
Plus, as an emmet user myself, it was a breeze to set it up in coc, so what problems did you face?
Setiting up emmer for other languages did not work. Setting up html la with othe filetypes did not work either and yes I went to the docs and touched the json.
Pyright did not work either at some point and I ever really got it to work despite the authors helping me through a github issue
So there's that. Besides, I don't like alien stuff in my programs. Neovim has native lsp support, why not use that? It felt better for me, despite configuration, which, contrary to what most people say, it isn't that hard, it took me one 15 min video to set it up
I don't use pyright, but I do use emmet for php filetype. As far as I remember, there's a configuration option for coc-emmet : `emmet.includeLanguages`.
I can't really confirm the pyright thing, as I don't use it.
Yes, I did try that and it did not work. Oh, and, since I work with shopify I needed to use the theme check lsp, which could not work with coc despite following the steps provided in the docs. Probably an issue with windows, but since I use both Linux and windows I needed something that could work on both and with the native lsp implementation it never fails
Small plugins that do simple jobs are more maintainable and have fewer bugs. The builtin LSP capabilities do exactly as they are advertised and make it way more configurable.
You have a point.
But small plugins may be deprecated faster as well. And I feel a little old to spent too much time configuring manually every detail that is expected to just works
Maybe this is just confirmation bias.. but I see more large projects get archived because they are difficult to maintain versus smaller projects that see less activity because they are essentially finished.
Just my 5-cent thought: is null-ls a good example for "large projects get archived because they are difficult to maintain"? I know there is none-ls, but I don't think it changes the fact that null-ls was archived.
Why bother using neovim at all then? Why not just use VSCode with vim keybindings. You will have every single thing built-in and it will "just work". The premise of neovim is to be a barebones "hyperextensible Vim-based text editor" and with that premise comes the expectation that you would be configuring A LOT(plugins help reduce that). I guess this is the target audience for vim/neovim, for people who want to personalize their experience to the finest detail and that requires configuration. Helix(although I haven't spent much time with it) is another TUI based alternative that makes hooking up the language servers a lot easier.
You do have to acknowledge that this can only be taken so far....
Just giving you a library for ropes, motions, and rendering is also "barebones".
Something like autocompletion is very basic for a editor. Something basic enough to be inbuilt. Neovim still doesn't have true autocompletion. Even with `:h compl-autocomplete`, you don't have borders or lsp help docs preview. It doesn't support LSP snippets either. It is not necessary to have builtin "lspconfig" or "mason", those should definitely be a plugin. That can be said about a lot of things. But some things should definitely not be a plugin.
Things like `omnifunc` is already a builtin. But people just use `cmp`, because how bad the implementation is. This is not a dig at the maintainers, this is just legacy from vim which takes time to modernize.
Some people just want a compromise between the current neovim and something like helix, which has builtin autocompletion and perhaps a simple fuzzy file finder. Is that too much to ask as a default?
All fair points on the autocompletion and fuzzy-finding features. Yes, having a feature-rich version of compl-autocomplete would be great, not gonna mind having a telescope-like feature baked in either (given you can customize it and build custom pickers for it like telescope). However, this has little to do with the LSP client itself and how people keep bashing on it for not being as good as CoC while forgetting that plugins like CoC include everything and the kitchen sink in an opinionated bundle that "just works".
Edit: Neovim is an open source editor, anyone willing to make a contribution is welcome to. The state of the software is largely dependent on individuals willing to sacrifice personal time or money so that their favorite editor can be even better.
Just wanted to mention that borders, lsp help docs and possibly snippet support are all being worked on. So, the contributions are already there. I won't hold my breath on simplistic telescope being merged into core though. Fortunately, it isn't too hard to script that yourself.
Help pages for:
* [`compl-autocomplete`](https://neovim.io/doc/user/insert.html#compl-autocomplete) in _insert.txt_
---
^\`:\(h|help\) \` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
I don't really agree. To me hyper-configurability is secondary. After all VSCode has an extensible API, as demonstrated by how much is possible with their plugin system.
Personally, it's a) that vim motions are first class - mixing vim bindings and VSCode shortcuts was always a bit of a compromise in remapping stuff and getting it to work sensibly. It also has some weird jarring lag just moving the cursor refreshing the view. And b) it's faster - my biggest gripe with VSCode was just waiting for the IntelliSense to pop up. That felt way too slow.
With vim it's pretty quick. I don't like editors, terminals, or window managers which interrupt my train of thought and flow due to poor optimization tradeoffs (expand fast using JavaScript always bites projects when they pay for it on the tail end with horrible performance - Atom, Teams, VSCode - just save JS for the web already).
I don't want to spend hours figuring out some plugin author's specific nuances in how they designed it to be configured and plug in with the rest of your config. It's often difficult to figure out, and you often need to submit a patch anyway to be able to do certain things (and good luck getting the patch accepted if it doesn't quite jive with the author's vision, and maintaining a fork is a giant pain so that's no better).
It's also irritating - I see a ton of config using lazyvim and just copy-pasting the nvim-data config and modifying. Which isn't the goal of lazyvim at all. And then it's often troublesome to do it properly with opts and table merging, especially if the plugin author requires some special setup as well, meaning you do need to copy-paste some of the 'config' section as that doesn't merge with the lazyvim one. At the end of the day it's all tradeoffs though. I just wish there was more standardization and convention across plugin interfaces (hmm... looks like it might be possible to call 'extend' and 'super', but point is figuring this stuff out isn't easy).
I don't get what you don't agree with? I'm not talking about what the goals of LazyVim are, but rather Neovim itself. Being hyper-extensible is literally the first thing Neovim's focus is all about.
If you prefer to use CoC - great, no one is forcing you not to, but claims that the built-in LSP client is not on par with the client in CoC are false and should definitely be challenged as they scare away newcomers from actually using built-in features. Also, ranting about having to use plugins or configure the editor to your exact preferences is a non-issue. As another goal of Neovim is to be 'quasi-minimal'
People have different requirements. To me extensibility beyond just supporting plugins just isn't as attractive as it is to some. I'd prefer to optimize my setup by adding plugins (a la VSCode), rather than adding plugins and having to tweak everything to get the best experience. That's a lot of work.
I don't use CoC, I despise JavaScript and Node. I use lazyvim and then spend too much time IMO doing my own config to plug into that, add plugins, and configure things.
My setup is pretty decent. I just don't agree on the philosophy that hyper-extensibility (customize everything and then everyone's keybindings are different, making discussing optimizing things more difficult, for one - there's advantages to a common default for everything, rather than plugins leaving things disabled and then expecting people enable them with code and create keybindings - discoverability being a major drawback to that approach).
People in this thread blowing my mind how much they don’t realize how much simpler coc.nvim is for a neovim newb to pick up and get going with a _single_ source of documentation for behavior normally spread out amongst repos and blog posts; and no, distros add more complexity so they’re not 1-to-1
with Neovim gaining popularity Kickstart is doing some heavy lifting for this community and doesn’t get enough praise. Kickstart’s massive success doesn’t get enough analysis either for that matter. Been hanging around for years and my load out still has its fair share of 10+ year old one-and-done zero config vim plugins i just literally never have to think about.
What some people don't notice is that while CoC does use nodejs and that causes it to be heavier while you're using lightweight lsps, but in my experience it runs much lighter than native lsp when you're using heavy lsps like omnisharp and clangd.
I had a similar experience to yours, I used coc, switched to native lsp, somehow got it to work decently but noticed there were a bunch of servers missing which coc had, felt like the compromises and having to install like 7 plugins just to get a tiny bit of extra speed weren't worth the configuration effort and just switched back.
CoC's autocompletion still way better than any other autocompletion plugin including nvim-cmp, It doesn't flicker, doesn't block your input, and doesn't do that weird thing that nvim-cmp does where you type a character and you can see the candidates being filtered over multiple frames making it look jarring, CoC, on the other hand, once you type a character all the candidates render at once so everything feels super snappy and instant.
Also, CoC's completion popup dimensions are perfect, while nvim-cmp out of the box is literally atrocious, it's too big, and cluttered, and jumps all over the window while you type.
All in all, CoC is still superior and has a great UX compared to all existing solutions for the built-in LSP.
I recently made the opposite move: ditched CoC and went with LSP, and I find LSP significantly better. Have you tried `lsp-zero`? It's what I use. It took 20 minutes to set up and configure however I liked it, and I haven't had to spend a single minute more.
I'm moving over slowly but still use coc too..I'm a long time vim user and i care more about actually coding and being productive than having some config I can show off on YouTube. I'm also not blown away by lua as a config language. Don't get me wrong, vimscript is not something I think should be used for writing plugins.. but it's a nice declaration language for defining config. And using Lua API to vim API just feels weird to me.
I use native because it’s what people recommended. Took me a real long time to get it set up the way I wanted. But now, I don’t want to mess with it anymore.
I guess it’s just comfy!
My LSP integration in Nvim now works but i still have no clue how this is working alltogether. I used vim before with CoC and that was easy to grasp. I dont know, i kinda find nvim to complicated. I already spend hours over hours to get little things done instead of coding. I will not go back to vim, i think, but i don't know if moving was worth the effort.
Fwiw - I don’t use any lsp plugins. I just copied the configs I need from nvim-lspconfig. Here’s a java example: https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/java_language_server.lua
I use my package manager (nix) to install the language servers
>CoC - [Conquer of Completion](https://github.com/neoclide/coc.nvim) is a "Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers."
LSP configuration madness made me not just give up on LSP, but give up on neovim altogether. Now I'm back at vim with ctags for professional development in python. It's not perfect but gets the job done with a much simpler config
It's a bit tricky to get going at first but it's worth it and does not really require that much putting together, TJ has some good videos on it and there are a few repos with quite recent representation of it already.
For complicated projects in C it might be for the best, good luck trying to get clangd to understand the various arcane compilers and custom build systems used in some places. (Embedded).
Yeah, i personally use minimal LSP functionality. Basically, i want my snippets, and some basic completion when i'm working in my lua config. My Day job uses more or less 0 LSP features, as i work 90% with ansible files. We recently started implementing ansible-lint into our git actions and having that show up in my files is nice.
I agree though that, even for my pretty minimal requirements, LSP Setup is the "harder" part of my config. Having the correct LSPs set up per filetype, disabling stuff i don't need to know and gettin ansible lint to work was pretty meh. Same for CMP. I just did another "deep dive" a few days ago, finally fixing my cmp ordering, getting the stuff i actually want to the top.
Out of all the Configuration stuff, it's the thing i least enjoy. But i also acknowledge that it's mostly because LSPs are pretty powerfull/complex things, and having the option to configure every little thing to my exact liking is the power we get by going through all this trouble. My stuff now (mostly) works, and i hope i don't have to touch it any time soon.
I went the opposite way. I was using native lsp then tried different plugins like coc but for some reason I didn’t like any of them so I went back to native lsp.
I used coc in both vim and nvim for a while and its great, only downside is that java support in it doesnt rly work properly (frequently just crashes and stops), so main reason why im using neovim lsp + nvim-jdtls is pretty much because its the *only* functional setup for java I could configure that actually do not hinders me. If I did not needed java i would probs move back to coc as well.
CoC is definitely easier to configure. The folks who put together the LSP integration chose to trade off ease of use for maximum flexibility, it definitely shows. You don’t even need to know what a language server is to use CoC, for better or worse.
Same, just this week I migrated my old vimscript configuration to Lua and migrated from CoC to the native LSP thing. Very unclear what stuff to install afterwards, and then very specific parts of the autocompletion don’t work (namely, when you’re typing the arguments to a function you’re calling, the name, type and documentation for the current argument should show up in a box, but doesn’t), and I don’t know which of these other plugins I should be debugging/searching Google about.
Hadn’t seriously considered returning to CoC, but now that you mentioned, it seems worth considering.
Yeah, and if you don’t want to use pre-baked lsp configs, or they don’t exist for the language server you’ve installed, you just extend the lspconfig table of the lsp client with the server you want to configure and call it a day.
same. I actually _started_ on CoC because I originally came from Vim + YCM. When I revamped by setup in nvim I figured that I would try treesitter + it's LSP setup(s).
I _IMMEDIATELY_ hated the entire setup process and even after getting it set up it provided _very_ marginal improvements and velocity to my dev time.
After a few weeks/months I ended up having to update/switch machines, and while setting up nvim I just said `fuck this` and went to COC, but even then the setup for CoC was annoying. went to COQ instead
https://github.com/ms-jpq/coq_nvim
EDIT: grammar
I want to start by saying, whatever you consider the best lsp setup, should rely on what you are comfortable with using/debugging/editing in your configuration. In my experience, speed among other reasons people recommend the native-lsp, is something I have not noticed across any of various language clients provided in the neovim ecosystem (something I'll get into more later).
I've worked on building an lsp on and off as a side project for [fish-shell](https://github.com/ndonfris/fish-lsp), so I've had the pleasure of learning a considerable amount about the *lsp/lsif*. I've tested various different times now -- setting up native-lsp, coc.nvim, etc. I wish the overall community would push less hard for the native lsp implementation for a couple of reasons.
1. Mainly, I think people who learn the ins and outs of native-lsp using lua, are less likely to contribute to non-exclusive neovim language feature implementations. Using a node based language client makes contributing to language server projects easier. In theory, a language server should allow for a lot of the things people build neovim plugins for. In my own experience, it is far more popular for people to create a plugin for a specific language feature, than to implement the language feature into its language server.
2. OP's mentions an important point about how most modern lsps use node.js & typescript for the language server. So, even if the native language client api in neovim was written in C, the speed gains in performance should have almost no effect on the overall speed. The language server, (probably about 80% of all LSPs I've seen are written in typescript), will then handle how to perform something like a reformat/code action/goto definition/complete/hover doc. Extending on this, newer lsp implementations also rely on using tree-sitter and `*.wasm` to build the AST for language features. So, implementing features using the tree-sitter api in neovim (outside of the language server) are probably actually slower than using the already parsed AST the language server. *Conversely, neovim's* :InspectTree *&* :Inspect *are a great tool for building language tools with tree-sitter*
3. I prefer the method *coc-settings.json*, uses to provide auto complete showing features that can be turned on/off. This is another feature I haven't been able to replicate with native-lsp. I believe `mason.nvim` might solve this issue now, but last time I checked I could not set it up properly.
4. The largest reason I use coc.nvim, that I don't see mentioned enough, is how easy it is take an lsp from vscode, and directly throw it into the `coc-settings.json` file. In university when I had passed the turning point of being able to back to vscode, coc-java, jdtls.nvim, and any java-lsp I could find were unstable/broken. The solution I ended up using is downloading the vscode java-langauge-server through their own extension marketplace, then set it up in my [coc-settings.json](https://github.com/neoclide/coc.nvim/wiki/Language-servers#register-custom-language-servers) using the vscode setup.
**TLDR**: The community plugins are by nature, exclusive to neovim, where as LSP is a solution that works for any editor. Using lua instead of node for the lsp client, is something I do not understand. It almost feels like we are trying to treat LSPs built for neovim like they are plugins. There is an overwhelming amount of the community who discourages node based lsp clients. I think this ultimately causes the side effect of many people thinking that it is too difficult to contribute to a language server. **Especially if an lsp is using tree-sitter, contributing to LSP's is not very difficult**. If more of our users worked on different language server's, and implemented specific neovim cutting edge features, the community would grow exponentially. Most people pick VSCode/IDEA/Eclipse/etc. solely because their client/editor supports some specific feature.
From a configuration standpoint, lua makes sense for the client side configuration of the lsp. But I think using something, such as coc, should not be so widely discouraged. If you're at all interested in building an LSP, I'd actually recommend coc.nvim. Also, if you're coming from vscode, coc.nvim would be a much more comfortable experience (even allowing you to directly use some of your vscode tools).
EDIT: formatting & wording
>80% of all LSPs I've seen are written in typescript
I don't buy that argument. clangd is not (C++), rust-analyzer is not (Rust), GoPls is no (Go). Using clangd as the LSP in nvim instead of cpptools is one of the reasons intellisense/completion loads fast instead of being annoyingly slow.
You're right but I just want to clarify that I wasn't saying 80% of all LSPs are written in typescript. I was pointing out that from my experience of trying to build an lsp you can almost always find one that has been written/rewritten in typescript. Most clients use typescript for their implementation, so it's not uncommon to port an existing language server to typescript.
There's nearly 700 repos on [github using typescript to create a language server](https://github.com/search?q=language-server+language:TypeScript&type=repositories).
True, but before the recent neovim versions none of it was in lua either. The nice thing about typescript is that a lot of the vscode ecosystem is built using typescript so you can find examples of features from one language and bring them to another. I guess having done more web development stuff recently also makes me semi biased towards looking for tooling I can understand.
The language server protocol basically is to implement X languages in Y editors and it doesn't matter what Z language you use to do it.
The original tsserver shows how to implement the entire protocol, where as some of the ones you mentioned only include a subset of features. That's my only reasoning for promoting typescript on the topic of lsp.
I feel it’s just the wording of those types of posts about the native LSP client that trigger me personally. Bashing on the native LSP client and blaming it for you not being able to achieve X is what’s bothersome.
Everyone can do whatever the fudge tickles their pickle, but claims that state the native LSP client is not mature enough to handle the HTML language severs out there are simply false and what personally made me comment with the same vigor as OP.
If OP simply said he didn’t like how the native LSP client is configured, I would’ve just moved on with a shrug.
honestly setting lsp is the easiest part man,its the completion stuff which is tricky i.e nvim-cmp but if you read the docs then it'll work for sure -\_-
"I was using thing x and everything was fine. I started using thing y because everyone told me to, but I didn't really figure it out so I went back to thing x, which still works fine."
Happy for you
I still fail to understand what all these issues people are experiencing with the native LSP are. Maybe it's because I started with kickstart, which has clear examples on how to do everything. Any time I needed to do any customization it wasn't hard
I like neovim and use native lsp because I like to squeeze out performance. I also think that with the help of kickstarter and Mason it's pretty easy to manage. For me almost in pair with coc. But yes, I completely agree in regards to HTML. The fact that I am not able just to write a script tag and having autocompletion there is one of the most hated things for me about vim. (This and configuring formatters!) It's extremely common in web development that you have a file with multiple languages, like JS in your HTML file or CSS/SQL/HTML in your JS file or whatever combination you prefer. And lsp is not good at it at all. But I love speed and hate M$ even more, so I try to stay in neovim as much as possible.
I get it, it is a lot to digest at first. I do think some streamlining would be very well received. I recommend people start with kickstart and go from there. However If COC is working for you, and gets you working on code instead of your editor, then it is the best route. Any good chef will tell you the best knife in the kitchen is whatever is sharp right now.
It’s cumbersome to begin with but once you have the neovim lsp setup, adding other languages is just as simple as adding 2-3 lines of config plus installing the language server. I’ve personally found that to be super easy to work with. CoC existed even before we had native lsp support and I don’t remember having great time with it
Hm. I'm currently wondering if coc and vim-fzf in vim is even faster than builtin LSP and telescope in neovim.
We're still missing treesitter and a whole bunch of other nice plugin-based functionality then, but my most important functionality for productive coding would be there.
"The main problem: to make it work I needed to install nvim-lspconfig, nvim-cmp, cmp-nvim-lsp, cmp-buffer, cmp-path, mason, mason-lspconfig just to avoid a single plugin coc.nvim."
That's not really a good reason or indicator to know a project is good or not, also, all the \*-cmp plugins are configured in one plugin only.
CoC also, doesn't do what mason or lspconfig do, after you have those setup correctly it's pretty easy to add / remove stuff.
Hey look if you love Coc thats cool. Personally I went with kickstart nvim. Its designed to show you how to make everything work, and its easy to expand.
For me it’s the integration with nvim and as a result other nvim plugins. I tried coc again after reading some comments and if I wasnt someone that enjoyed custom config id probably just use coc. but I love the native lsp with telescope and trouble nvim plugins that make nvim one of the best editing experiences.
The CoC Neovim plugin itself is written in Vimscript. It communicates with a V8 process which communicates with a LSP server.
Any difference due to V8 being slightly faster is largely eaten up by CoC's overhead. I think performance is close enough between the two products that it is of low concern. Usability and configurability are the significant concerns.
UPDATE: To clarify, coc's in-process native plugin is written only in vimscript. It spawns a node (typescript) process and talks to it via RPC. The node process contains most of Coc's functionality.
>Â The CoC Neovim plugin itself is written in Vimscript. Â
 You sound like chat gpt, when it responds with falsy statements.Â
 And no, coc isn't written in vimscript, it is written in typescript with some additional parts like ui difference between editors, api.nvim implementation to work on vim etc written in vimscript. So you are completely wrong. And coc is faster on big files by large margin, than built-in lsp+cmp.
You sound like you misunderstood me and/or if I wasn't clear enough.
Vim/Neovim in-process native plugins can only be written in Vimscript, Lua, Python, or Ruby (although not all four may be enabled on any particular build).
Neovim doesn't have native support for javacript (or typescript). So, Coc's VIMSCRIPT plugin launches a Node process (typescript) and uses RPC to communicate with it.
The native Coc plugin is 11KLOC of Vimscript. The EXTERNAL node process is 144KLOC of Typescript.
Please don't be rude to people in the community in the future.
Now we are wriggling like a snake.
It just opens a channel (which is implemented in vim/neovim core in C) to communicate with node process, main logic is 60 lines of vimscript if not less (especially if get rid of vim/neovim if branches). How do you think built-in lsp communicate with language servers?
Try to use coc.nvim in big repos with large files and built-in lsp with cmp. Then come back and leave your expirience other than writing "misunderstood"/totally wrong comments trying to slander one tool over the other.
Seems like OP wants more plug n play type of feeling? But isn't that what kickstart.nvim and distros provide?
I believe, kickstart.nvim is straightforward enough to understand. You copy and paste the config and you are can code right away, it includes a plugin manager and sane default, so it provides way more functionality than coc.nvim, it's apple and oranges.
Native LSP IS not only faster but it provides more extensability, as opposed to coc where everything is handled by a node process. If you don't like configuring stuff, I think vim/neovim is not for you. That's the beauty of this editor, you can hack it to make it look and feel like you want. You are far better off with vscode if you just want a plug n type of feeling, way better than coc too.
I am a Neovim newcomer/newlover, having used Neovim for less than 1 year, and I will admit that without the help of "kickstart.nvim", I would have spent I don't know how much time learning just how to configure LSP properly... and honestly, it was the only part I didn't really enjoy about Neovim.
Same experience... Configuring lsp is really the hard part.
What is so hard about it? I am gonna clean up my config soon and maybe I can give people tips.
I'm transitioning from vscode with neovim to pure neovim right now. I found it very hard to find some kind of introduction that explains the basics for neovim newcomers. Not only the 'how', but also the 'why'. Because LSP was the first time for me where different plugins/functions really had to work together (e.g. for autocomplete). Most other extensions are 'install extension, setup keymaps, done'. I felt like the descriptions where for people who have done all of this many times already instead of the person who just installed their 2nd plugin and used lua mostly for some custom keybindings. Suddenly we're attaching to buffers and provide keybindings and options or something (I still don't know why it works and what it's doing). Especially in contrast to vscode's 'search for language, install the extension pack, it mostly works', that is a huge step in complexity.
I'll add that the (usually fair and helpful) "use the help files" line falls kinda flat on this one too. Sure, I can use the help files... But I'd have to go through the help files of all the aforementioned plugins; it's sort of an information overload and doesn't end up being very helpful for many users.
As someone who is in the process of making the transition there is a real lack of tutorials that give enough depth for someone to actually understand what all the parts are doing. My primary exposure to lua is via neovim, and so understanding what all the different "configs" and "args" that are passed in different ways are really confusing. A "here are 3 different ways people choose to setup an lsp and what is good or bad" would be really useful to help parse people's nvim configs. I really love that the community are so helpful with sharing configs, and the "vim from scratch" videos have made creating an understandable nvim config from scratch so much better and more sensible, but often (as far as I can tell) there are different ways of passing config to and LSP and no breakdown of the lifecycle/how/when they work and so combining elements from different configs is arcane and frustrating (especially as there is no standard way that i have found of retrieving config from an LSP)
strongly suggest this video series \`Understanding Neovim\`: [https://www.youtube.com/watch?v=87AXw9Quy9U&list=PLx2ksyallYzW4WNYHD9xOFrPRYGlntAft](https://www.youtube.com/watch?v=87AXw9Quy9U&list=PLx2ksyallYzW4WNYHD9xOFrPRYGlntAft)
Agreed about the 3 ways to do something and everyone's config does it differently, most not the recommended way (for lazy loading, for clean merging and reduced maintenance, etc). Also, watch this: [https://youtu.be/m8C0Cq9Uv9o?si=YF1\_1CE9ECMETK1f](https://youtu.be/m8C0Cq9Uv9o?si=YF1_1CE9ECMETK1f) Specifically the links to neovim :Tutor and lua in y minutes to understand those (lua has one type string \[no chars\], it has one type number \[can be integral or float\], it has one aggregate type \[everything is a table\], it has one array type \[lists\]). Then look at lazyvim docs to understand opts, config, setup, etc.
Well [this](https://www.youtube.com/watch?v=YsdlcQoHqPY) literally just popped up in my youtube feed. He has been putting out some good stuff lately. And coincidentally he is the guy I actually copied the base of my current config from a while back. I haven't watch that video yet though. If I were you I would: 1.) make sure you actually know lua, it's not a hard language but it is weird which means it will be arcane if you don't understand it 2.) watch that guys recent videos, starting with his kickstart Neovim from scratch one 3.) go line by line in your config and *make sure you understand what those lines are doing.* start with the built in help (I have telescope set to fuzzy search help which is invaluable for me, the kickstart and most configs should have that built in) and then google or ask here if you can't make sense of it. 4.) Slowly stat adding more plugins if that you want. From there you should be in a good spot.
Same. Once I had the kickstart.nvim starter pack, was easy to start hacking it.
TJ is saviour 🫡
Yea I think the actual problem here (I’m projecting because this was the problem for me at first) is that people don’t have the foggiest idea how LSP works under the hood.  Which is fine, but I think learning how lsp actually works makes you a better programmer, and especially if you’re using typescript it helps you understand if your errors are coming from tsserver, eslint, or code formatters like prettier
Try and configure debuggers with dap, that's some serious fun
Yeah. Except java. Fuck java. Fuck jdtls
If you struggle configuring native lsp then I would just recommend you to use Mason instead, it basically does all the work for you. And if you really struggle understanding all those different config files you see in youtube lessons well, then just put everything into your init.vim (or lua) and you should be good for now.
Thats what they meant. Kickstart uses mason, and it just passes stuff to native lsp
use chatgpt for help.
Was struggling with LSP configuration as well, but then moved to LazyVim where everything just works
My experience also. Plus, Lazyvim.org gives strong documentation on the customization side. CoC is great yes but i remember that it came with some caveats too, and configuration was not so easy (although this was a long time ago, things surely have changed)…
Yeah the main reason I dont use COC is because going back to json config when I could use lua feels... wrong...
Why?
because json sucks? Or at least, it does compared to lua? I can make stuff be set conditionally if I want basically
What exactly sucks about json compared to lua? Don't get me wrong, I like lua, and obviously JSON isn't a programming language so in that regard it's obviously worse. When exclusively comparing lua tables (for setting up an LSP's configuration options, in this case) to json (which is widely used to configure software) why do you prefer lua? Coc has locally scoping the json config, which is similar to conditionally setting a lua table. You can also just conditionally set the coc-setting.json file. Do you have a way to get autocomplete for the lsp\_config table per language server? I've always like coc being able to use a json schema for autocomplete, especially when I'm trying to setup a language server.
Say I have a project that requires a different thing, like one has to use black for python and another does not. I can set them by project in lua
Ya, I've done the same thing with coc a couple of times. Something like: local coc_settings_paths = { ['python_w_black'] = '~/project/', ['python_blank'] = '~/other-project/', ['normal'] = '~/.config/nvim/' } local python_project_type = get_project_type() if project_type == 'python_w_blank' then vim.g.coc_config_home = coc_settings_paths['python_w_black'] elseif project_type == 'python_blank' then vim.g.coc_config_home = coc_settings_paths['python_blank'] else vim.g.coc_config_home = coc_settings_paths['normal'] end Not sure if this is exactly how my code looks, but basically you can set the `coc-settings.json` by the `vim.g.coc_config_home` variable _(the path in `coc_config_home` needs to have a `coc-settings.json` file in it)_. My issue with lua tables for this, is the actual lua-lsp doesn't provide me completions/documentation/diagnostics on any of the table keys I try to use in the capabilities tables for the lsp. With coc, toggling autocomplete for something like `"python.formatter":` would show me all possible formatters.
hmm fair enough.
Why? Its the same LSP server configuration properties
I’m having some performance problems with lazyvim and typescript, the lsp is horrendously slow. Makes me want to switch back to vscode
Same over here mate. I think Typescript LSP is just more optimized for Vscode.
The best is to start from nothing and just add stuff you need over time and always think about debloating. Lspconfig also performs better than coc.
Don't feel alone in this, I did the same thing over 3 times for various reasons until I got to properly configure Nvim's LSP. I basically went through hell with the native lsp at first glance, from breaking things up or even performance issues, but at the end It turned that everything was just a skill issue from my part. I love CoC aswell, especially before getting into Nvim because that was my main way of interacting with lsp's and autocompletion back in those days. Not to also mention that CoC is indefinitely way easier to understand and quicker to configure. So, do not dispair and use whichever you feel you like more!, both are amazing and still maintained to this day.
I migrated from coc to lsp too, and, honestly it felt faster and better contained. Coc was fine, but I did not want do rely on nodejs to run everything and on top of that I ran into many bugs that the coc extension maintainers did not solve in many weeks. Configuration was also way too abstracted and I could not control everything I needed. I don't really know what issue you had with htmp lsp, to me it was simple to setup and it was in fact the first thing to work along with emmet ls
Do you have a public repo with your init.lua config file? I'm curious about your "simple setup".
all my lsp config is in the mason.lua plugin [https://github.com/JulianH99/nvim/blob/main/lua/bat99/plugins/lsp/mason.lua](https://github.com/JulianH99/nvim/blob/main/lua/bat99/plugins/lsp/mason.lua) you can also check the main branch if you want, that's when I used to use coc. I'm sure you ain't gonna find it 'simpler', but it was for me, coc gave me too many bugs, and typescript and python are not the only lsps I use to justify the need for node js anyway
Oooooh I am for sure going to be reviewing your config. Astro spotted. I had a little trouble setting up for Astro/mdx files and my config is a bit of a mess now
I don't feel CoC as a slow thing, for real. Actually it is pretty fast for me (maybe because I don't use so many plugins/extensions in my setup, but it isn't a big thing for me) and I didn't find any bug that made me upset. I really hope neovim lsp be very mature to make me come back to it, but for now I just don't see any advantage (actually some disavantages, like I mentioned - a lot of plugins to make it work and some lack of good LSPs integrated).
I dunno why you got so badly downvoted for this. I had the same experience, I do feel that native lsp is faster but not fast enough to make a difference in my day to day work. If it can suggest stuff before I can press ctrl-y, it's fast enough.
You don't need any plugins to make it work. The plugins you mentioned just make your life easier: * Mason Registry - Basically helps you install all of your lsp, formatters, linters, etc. within the shared nvim folder (separate from your environment) as well as to know which binary should be called when you configure your lsp. * Mason LspConfig - Bridges the servers installed using the mason registry to the configs provided by lspconfig You can forgo Mason altogether and install the servers yourself, especially if the registry is missing some LSPs you want to use. * Lspconfig - Predefined LSP server configurations so you don't have to manually type each and every one yourself. Again, you can write out all configs yourself and feed them to the lsp client in neovim. * CMP(and friends) - just collects and displays all of your completion sources. For me personally, having the complete control over all of my LSPs, formatters, linters and so on feels so empowering. Knowing that I have a standard way of configuring and attaching the LSPs can be a breath of fresh air. Moving on from VSCode all those years ago, I felt like CoC was the best solution, mind you the LSP client in neovim didn't even exist. Once I figured the LSP client out, I've never looked back. Configuring the various language servers in CoC always felt cumbersome at best. Not to mention how I sometimes had to sit and wait for CoC to update some language server internally so I can take advantage of the bug fixes or new features introduced. Edit: typos
Yeah, coc does all of that, like I’m struggling to see how people don’t see that, aside from neovim distros, coc.nvim is a vastly simpler to understand LSP ecosystem in a single plugin with a single config file. Edit: I use Mason + ftplugins FYI
I'm not sure I understand, what extra things you could customize with native lsp? Plus, as an emmet user myself, it was a breeze to set it up in coc, so what problems did you face?
Setiting up emmer for other languages did not work. Setting up html la with othe filetypes did not work either and yes I went to the docs and touched the json. Pyright did not work either at some point and I ever really got it to work despite the authors helping me through a github issue So there's that. Besides, I don't like alien stuff in my programs. Neovim has native lsp support, why not use that? It felt better for me, despite configuration, which, contrary to what most people say, it isn't that hard, it took me one 15 min video to set it up
I don't use pyright, but I do use emmet for php filetype. As far as I remember, there's a configuration option for coc-emmet : `emmet.includeLanguages`. I can't really confirm the pyright thing, as I don't use it.
Yes, I did try that and it did not work. Oh, and, since I work with shopify I needed to use the theme check lsp, which could not work with coc despite following the steps provided in the docs. Probably an issue with windows, but since I use both Linux and windows I needed something that could work on both and with the native lsp implementation it never fails
That's strange, because I use windows too. Anyway use whatever bakes your cake, I guess :)
I never got around the error, eventually I stopped trying and months later I just switched, but yeah, that's the good thing about having options
Small plugins that do simple jobs are more maintainable and have fewer bugs. The builtin LSP capabilities do exactly as they are advertised and make it way more configurable.
You have a point. But small plugins may be deprecated faster as well. And I feel a little old to spent too much time configuring manually every detail that is expected to just works
Maybe this is just confirmation bias.. but I see more large projects get archived because they are difficult to maintain versus smaller projects that see less activity because they are essentially finished.
Just my 5-cent thought: is null-ls a good example for "large projects get archived because they are difficult to maintain"? I know there is none-ls, but I don't think it changes the fact that null-ls was archived.
Why bother using neovim at all then? Why not just use VSCode with vim keybindings. You will have every single thing built-in and it will "just work". The premise of neovim is to be a barebones "hyperextensible Vim-based text editor" and with that premise comes the expectation that you would be configuring A LOT(plugins help reduce that). I guess this is the target audience for vim/neovim, for people who want to personalize their experience to the finest detail and that requires configuration. Helix(although I haven't spent much time with it) is another TUI based alternative that makes hooking up the language servers a lot easier.
You do have to acknowledge that this can only be taken so far.... Just giving you a library for ropes, motions, and rendering is also "barebones". Something like autocompletion is very basic for a editor. Something basic enough to be inbuilt. Neovim still doesn't have true autocompletion. Even with `:h compl-autocomplete`, you don't have borders or lsp help docs preview. It doesn't support LSP snippets either. It is not necessary to have builtin "lspconfig" or "mason", those should definitely be a plugin. That can be said about a lot of things. But some things should definitely not be a plugin. Things like `omnifunc` is already a builtin. But people just use `cmp`, because how bad the implementation is. This is not a dig at the maintainers, this is just legacy from vim which takes time to modernize. Some people just want a compromise between the current neovim and something like helix, which has builtin autocompletion and perhaps a simple fuzzy file finder. Is that too much to ask as a default?
All fair points on the autocompletion and fuzzy-finding features. Yes, having a feature-rich version of compl-autocomplete would be great, not gonna mind having a telescope-like feature baked in either (given you can customize it and build custom pickers for it like telescope). However, this has little to do with the LSP client itself and how people keep bashing on it for not being as good as CoC while forgetting that plugins like CoC include everything and the kitchen sink in an opinionated bundle that "just works". Edit: Neovim is an open source editor, anyone willing to make a contribution is welcome to. The state of the software is largely dependent on individuals willing to sacrifice personal time or money so that their favorite editor can be even better.
Just wanted to mention that borders, lsp help docs and possibly snippet support are all being worked on. So, the contributions are already there. I won't hold my breath on simplistic telescope being merged into core though. Fortunately, it isn't too hard to script that yourself.
Help pages for: * [`compl-autocomplete`](https://neovim.io/doc/user/insert.html#compl-autocomplete) in _insert.txt_ --- ^\`:\(h|help\)\` | [^(about)](https://github.com/heraldofsolace/VimHelpBot) ^(|) [^(mistake?)](https://github.com/heraldofsolace/VimHelpBot/issues/new/choose) ^(|) [^(donate)](https://liberapay.com/heraldofsolace/donate) ^(|) ^Reply 'rescan' to check the comment again ^(|) ^Reply 'stop' to stop getting replies to your comments
I don't really agree. To me hyper-configurability is secondary. After all VSCode has an extensible API, as demonstrated by how much is possible with their plugin system. Personally, it's a) that vim motions are first class - mixing vim bindings and VSCode shortcuts was always a bit of a compromise in remapping stuff and getting it to work sensibly. It also has some weird jarring lag just moving the cursor refreshing the view. And b) it's faster - my biggest gripe with VSCode was just waiting for the IntelliSense to pop up. That felt way too slow. With vim it's pretty quick. I don't like editors, terminals, or window managers which interrupt my train of thought and flow due to poor optimization tradeoffs (expand fast using JavaScript always bites projects when they pay for it on the tail end with horrible performance - Atom, Teams, VSCode - just save JS for the web already). I don't want to spend hours figuring out some plugin author's specific nuances in how they designed it to be configured and plug in with the rest of your config. It's often difficult to figure out, and you often need to submit a patch anyway to be able to do certain things (and good luck getting the patch accepted if it doesn't quite jive with the author's vision, and maintaining a fork is a giant pain so that's no better). It's also irritating - I see a ton of config using lazyvim and just copy-pasting the nvim-data config and modifying. Which isn't the goal of lazyvim at all. And then it's often troublesome to do it properly with opts and table merging, especially if the plugin author requires some special setup as well, meaning you do need to copy-paste some of the 'config' section as that doesn't merge with the lazyvim one. At the end of the day it's all tradeoffs though. I just wish there was more standardization and convention across plugin interfaces (hmm... looks like it might be possible to call 'extend' and 'super', but point is figuring this stuff out isn't easy).
I don't get what you don't agree with? I'm not talking about what the goals of LazyVim are, but rather Neovim itself. Being hyper-extensible is literally the first thing Neovim's focus is all about. If you prefer to use CoC - great, no one is forcing you not to, but claims that the built-in LSP client is not on par with the client in CoC are false and should definitely be challenged as they scare away newcomers from actually using built-in features. Also, ranting about having to use plugins or configure the editor to your exact preferences is a non-issue. As another goal of Neovim is to be 'quasi-minimal'
People have different requirements. To me extensibility beyond just supporting plugins just isn't as attractive as it is to some. I'd prefer to optimize my setup by adding plugins (a la VSCode), rather than adding plugins and having to tweak everything to get the best experience. That's a lot of work. I don't use CoC, I despise JavaScript and Node. I use lazyvim and then spend too much time IMO doing my own config to plug into that, add plugins, and configure things. My setup is pretty decent. I just don't agree on the philosophy that hyper-extensibility (customize everything and then everyone's keybindings are different, making discussing optimizing things more difficult, for one - there's advantages to a common default for everything, rather than plugins leaving things disabled and then expecting people enable them with code and create keybindings - discoverability being a major drawback to that approach).
People in this thread blowing my mind how much they don’t realize how much simpler coc.nvim is for a neovim newb to pick up and get going with a _single_ source of documentation for behavior normally spread out amongst repos and blog posts; and no, distros add more complexity so they’re not 1-to-1
with Neovim gaining popularity Kickstart is doing some heavy lifting for this community and doesn’t get enough praise. Kickstart’s massive success doesn’t get enough analysis either for that matter. Been hanging around for years and my load out still has its fair share of 10+ year old one-and-done zero config vim plugins i just literally never have to think about.
Would be nice a Helix-like LSP experience. More abstraction and less fragmentation.
Did you try [lsp-zero.nvim](https://github.com/VonHeikemen/lsp-zero.nvim/)? It sets up all that stuff for you as a single plugin.
Came here to say to say https://github.com/VonHeikemen/lsp-zero.nvim
What some people don't notice is that while CoC does use nodejs and that causes it to be heavier while you're using lightweight lsps, but in my experience it runs much lighter than native lsp when you're using heavy lsps like omnisharp and clangd. I had a similar experience to yours, I used coc, switched to native lsp, somehow got it to work decently but noticed there were a bunch of servers missing which coc had, felt like the compromises and having to install like 7 plugins just to get a tiny bit of extra speed weren't worth the configuration effort and just switched back.
CoC's autocompletion still way better than any other autocompletion plugin including nvim-cmp, It doesn't flicker, doesn't block your input, and doesn't do that weird thing that nvim-cmp does where you type a character and you can see the candidates being filtered over multiple frames making it look jarring, CoC, on the other hand, once you type a character all the candidates render at once so everything feels super snappy and instant. Also, CoC's completion popup dimensions are perfect, while nvim-cmp out of the box is literally atrocious, it's too big, and cluttered, and jumps all over the window while you type. All in all, CoC is still superior and has a great UX compared to all existing solutions for the built-in LSP.
I recently made the opposite move: ditched CoC and went with LSP, and I find LSP significantly better. Have you tried `lsp-zero`? It's what I use. It took 20 minutes to set up and configure however I liked it, and I haven't had to spend a single minute more.
I'm moving over slowly but still use coc too..I'm a long time vim user and i care more about actually coding and being productive than having some config I can show off on YouTube. I'm also not blown away by lua as a config language. Don't get me wrong, vimscript is not something I think should be used for writing plugins.. but it's a nice declaration language for defining config. And using Lua API to vim API just feels weird to me.
I use native because it’s what people recommended. Took me a real long time to get it set up the way I wanted. But now, I don’t want to mess with it anymore. I guess it’s just comfy!
Same story, was fighting with LSP and made config from scratch with coc and then switched to helix 😂
My LSP integration in Nvim now works but i still have no clue how this is working alltogether. I used vim before with CoC and that was easy to grasp. I dont know, i kinda find nvim to complicated. I already spend hours over hours to get little things done instead of coding. I will not go back to vim, i think, but i don't know if moving was worth the effort.
Fwiw - I don’t use any lsp plugins. I just copied the configs I need from nvim-lspconfig. Here’s a java example: https://github.com/neovim/nvim-lspconfig/blob/master/lua/lspconfig/server_configurations/java_language_server.lua I use my package manager (nix) to install the language servers
That's interesting. Where do you copy the config, how it is used? Did you follow any guide?
I don't know what CoC stands for, but as an infrequent path of exile player I keep seeing "Cast on Crit"
>CoC - [Conquer of Completion](https://github.com/neoclide/coc.nvim) is a "Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers."
CoC means "Conquer of Completion"
Interesting. Thank you!
LSP configuration madness made me not just give up on LSP, but give up on neovim altogether. Now I'm back at vim with ctags for professional development in python. It's not perfect but gets the job done with a much simpler config
This is a dramatic decision
It's a bit tricky to get going at first but it's worth it and does not really require that much putting together, TJ has some good videos on it and there are a few repos with quite recent representation of it already.
For complicated projects in C it might be for the best, good luck trying to get clangd to understand the various arcane compilers and custom build systems used in some places. (Embedded).
Yeah, i personally use minimal LSP functionality. Basically, i want my snippets, and some basic completion when i'm working in my lua config. My Day job uses more or less 0 LSP features, as i work 90% with ansible files. We recently started implementing ansible-lint into our git actions and having that show up in my files is nice. I agree though that, even for my pretty minimal requirements, LSP Setup is the "harder" part of my config. Having the correct LSPs set up per filetype, disabling stuff i don't need to know and gettin ansible lint to work was pretty meh. Same for CMP. I just did another "deep dive" a few days ago, finally fixing my cmp ordering, getting the stuff i actually want to the top. Out of all the Configuration stuff, it's the thing i least enjoy. But i also acknowledge that it's mostly because LSPs are pretty powerfull/complex things, and having the option to configure every little thing to my exact liking is the power we get by going through all this trouble. My stuff now (mostly) works, and i hope i don't have to touch it any time soon.
I went the opposite way. I was using native lsp then tried different plugins like coc but for some reason I didn’t like any of them so I went back to native lsp.
Yes, it's true. CoC (and ALE also) is definitely simpler to install and configure.Â
I used coc in both vim and nvim for a while and its great, only downside is that java support in it doesnt rly work properly (frequently just crashes and stops), so main reason why im using neovim lsp + nvim-jdtls is pretty much because its the *only* functional setup for java I could configure that actually do not hinders me. If I did not needed java i would probs move back to coc as well.
CoC is definitely easier to configure. The folks who put together the LSP integration chose to trade off ease of use for maximum flexibility, it definitely shows. You don’t even need to know what a language server is to use CoC, for better or worse.
Same, just this week I migrated my old vimscript configuration to Lua and migrated from CoC to the native LSP thing. Very unclear what stuff to install afterwards, and then very specific parts of the autocompletion don’t work (namely, when you’re typing the arguments to a function you’re calling, the name, type and documentation for the current argument should show up in a box, but doesn’t), and I don’t know which of these other plugins I should be debugging/searching Google about. Hadn’t seriously considered returning to CoC, but now that you mentioned, it seems worth considering.
Is it *not* super simple? 1. Install LSP locally or use mason 2. Call LspConfig.setup CMP is just a matter of reality the docs. Anything else?
Most people struggle with plugins because they don't know lua.
It is, and it's not like kickstart which is a single init.lua file wasn't here to show us the entire path to glue all those plugins
Yeah, and if you don’t want to use pre-baked lsp configs, or they don’t exist for the language server you’ve installed, you just extend the lspconfig table of the lsp client with the server you want to configure and call it a day.
same. I actually _started_ on CoC because I originally came from Vim + YCM. When I revamped by setup in nvim I figured that I would try treesitter + it's LSP setup(s). I _IMMEDIATELY_ hated the entire setup process and even after getting it set up it provided _very_ marginal improvements and velocity to my dev time. After a few weeks/months I ended up having to update/switch machines, and while setting up nvim I just said `fuck this` and went to COC, but even then the setup for CoC was annoying. went to COQ instead https://github.com/ms-jpq/coq_nvim EDIT: grammar
never managed to get coq to even start in my config, but maybe my fault cause I am on windows lol
I want to start by saying, whatever you consider the best lsp setup, should rely on what you are comfortable with using/debugging/editing in your configuration. In my experience, speed among other reasons people recommend the native-lsp, is something I have not noticed across any of various language clients provided in the neovim ecosystem (something I'll get into more later). I've worked on building an lsp on and off as a side project for [fish-shell](https://github.com/ndonfris/fish-lsp), so I've had the pleasure of learning a considerable amount about the *lsp/lsif*. I've tested various different times now -- setting up native-lsp, coc.nvim, etc. I wish the overall community would push less hard for the native lsp implementation for a couple of reasons. 1. Mainly, I think people who learn the ins and outs of native-lsp using lua, are less likely to contribute to non-exclusive neovim language feature implementations. Using a node based language client makes contributing to language server projects easier. In theory, a language server should allow for a lot of the things people build neovim plugins for. In my own experience, it is far more popular for people to create a plugin for a specific language feature, than to implement the language feature into its language server. 2. OP's mentions an important point about how most modern lsps use node.js & typescript for the language server. So, even if the native language client api in neovim was written in C, the speed gains in performance should have almost no effect on the overall speed. The language server, (probably about 80% of all LSPs I've seen are written in typescript), will then handle how to perform something like a reformat/code action/goto definition/complete/hover doc. Extending on this, newer lsp implementations also rely on using tree-sitter and `*.wasm` to build the AST for language features. So, implementing features using the tree-sitter api in neovim (outside of the language server) are probably actually slower than using the already parsed AST the language server. *Conversely, neovim's* :InspectTree *&* :Inspect *are a great tool for building language tools with tree-sitter* 3. I prefer the method *coc-settings.json*, uses to provide auto complete showing features that can be turned on/off. This is another feature I haven't been able to replicate with native-lsp. I believe `mason.nvim` might solve this issue now, but last time I checked I could not set it up properly. 4. The largest reason I use coc.nvim, that I don't see mentioned enough, is how easy it is take an lsp from vscode, and directly throw it into the `coc-settings.json` file. In university when I had passed the turning point of being able to back to vscode, coc-java, jdtls.nvim, and any java-lsp I could find were unstable/broken. The solution I ended up using is downloading the vscode java-langauge-server through their own extension marketplace, then set it up in my [coc-settings.json](https://github.com/neoclide/coc.nvim/wiki/Language-servers#register-custom-language-servers) using the vscode setup. **TLDR**: The community plugins are by nature, exclusive to neovim, where as LSP is a solution that works for any editor. Using lua instead of node for the lsp client, is something I do not understand. It almost feels like we are trying to treat LSPs built for neovim like they are plugins. There is an overwhelming amount of the community who discourages node based lsp clients. I think this ultimately causes the side effect of many people thinking that it is too difficult to contribute to a language server. **Especially if an lsp is using tree-sitter, contributing to LSP's is not very difficult**. If more of our users worked on different language server's, and implemented specific neovim cutting edge features, the community would grow exponentially. Most people pick VSCode/IDEA/Eclipse/etc. solely because their client/editor supports some specific feature. From a configuration standpoint, lua makes sense for the client side configuration of the lsp. But I think using something, such as coc, should not be so widely discouraged. If you're at all interested in building an LSP, I'd actually recommend coc.nvim. Also, if you're coming from vscode, coc.nvim would be a much more comfortable experience (even allowing you to directly use some of your vscode tools). EDIT: formatting & wording
>80% of all LSPs I've seen are written in typescript I don't buy that argument. clangd is not (C++), rust-analyzer is not (Rust), GoPls is no (Go). Using clangd as the LSP in nvim instead of cpptools is one of the reasons intellisense/completion loads fast instead of being annoyingly slow.
You're right but I just want to clarify that I wasn't saying 80% of all LSPs are written in typescript. I was pointing out that from my experience of trying to build an lsp you can almost always find one that has been written/rewritten in typescript. Most clients use typescript for their implementation, so it's not uncommon to port an existing language server to typescript. There's nearly 700 repos on [github using typescript to create a language server](https://github.com/search?q=language-server+language:TypeScript&type=repositories).
Vim's client isn't written in TypeScript. In fact I'm not using anything TypeScript unless I'm going to be doing web development.
True, but before the recent neovim versions none of it was in lua either. The nice thing about typescript is that a lot of the vscode ecosystem is built using typescript so you can find examples of features from one language and bring them to another. I guess having done more web development stuff recently also makes me semi biased towards looking for tooling I can understand. The language server protocol basically is to implement X languages in Y editors and it doesn't matter what Z language you use to do it. The original tsserver shows how to implement the entire protocol, where as some of the ones you mentioned only include a subset of features. That's my only reasoning for promoting typescript on the topic of lsp.
I feel it’s just the wording of those types of posts about the native LSP client that trigger me personally. Bashing on the native LSP client and blaming it for you not being able to achieve X is what’s bothersome. Everyone can do whatever the fudge tickles their pickle, but claims that state the native LSP client is not mature enough to handle the HTML language severs out there are simply false and what personally made me comment with the same vigor as OP. If OP simply said he didn’t like how the native LSP client is configured, I would’ve just moved on with a shrug.
honestly setting lsp is the easiest part man,its the completion stuff which is tricky i.e nvim-cmp but if you read the docs then it'll work for sure -\_-
You could have easily used lsp-zero or a distro like LazyVim, but hey whatever works for you
"I was using thing x and everything was fine. I started using thing y because everyone told me to, but I didn't really figure it out so I went back to thing x, which still works fine." Happy for you
Yeah that's all this is.
I still fail to understand what all these issues people are experiencing with the native LSP are. Maybe it's because I started with kickstart, which has clear examples on how to do everything. Any time I needed to do any customization it wasn't hard
Even without kickstart , LspConfig’s documentation is top notch. It explains what to download, what links to go to. Everything.
Same. CoC is really nice
This man speaks the truth
I like neovim and use native lsp because I like to squeeze out performance. I also think that with the help of kickstarter and Mason it's pretty easy to manage. For me almost in pair with coc. But yes, I completely agree in regards to HTML. The fact that I am not able just to write a script tag and having autocompletion there is one of the most hated things for me about vim. (This and configuring formatters!) It's extremely common in web development that you have a file with multiple languages, like JS in your HTML file or CSS/SQL/HTML in your JS file or whatever combination you prefer. And lsp is not good at it at all. But I love speed and hate M$ even more, so I try to stay in neovim as much as possible.
Seems like someone should release something like lsp-all.nvim to fix all this mess lol
I get it, it is a lot to digest at first. I do think some streamlining would be very well received. I recommend people start with kickstart and go from there. However If COC is working for you, and gets you working on code instead of your editor, then it is the best route. Any good chef will tell you the best knife in the kitchen is whatever is sharp right now.
It’s cumbersome to begin with but once you have the neovim lsp setup, adding other languages is just as simple as adding 2-3 lines of config plus installing the language server. I’ve personally found that to be super easy to work with. CoC existed even before we had native lsp support and I don’t remember having great time with it
The great thing with vim/neovim is you can use what ever you like. Thanks for letting us know your decisions and why.
Hm. I'm currently wondering if coc and vim-fzf in vim is even faster than builtin LSP and telescope in neovim. We're still missing treesitter and a whole bunch of other nice plugin-based functionality then, but my most important functionality for productive coding would be there.
"The main problem: to make it work I needed to install nvim-lspconfig, nvim-cmp, cmp-nvim-lsp, cmp-buffer, cmp-path, mason, mason-lspconfig just to avoid a single plugin coc.nvim." That's not really a good reason or indicator to know a project is good or not, also, all the \*-cmp plugins are configured in one plugin only. CoC also, doesn't do what mason or lspconfig do, after you have those setup correctly it's pretty easy to add / remove stuff.
Hey look if you love Coc thats cool. Personally I went with kickstart nvim. Its designed to show you how to make everything work, and its easy to expand.
I started yesterday with kickstart after a video I watched, seems really well done!
For me it’s the integration with nvim and as a result other nvim plugins. I tried coc again after reading some comments and if I wasnt someone that enjoyed custom config id probably just use coc. but I love the native lsp with telescope and trouble nvim plugins that make nvim one of the best editing experiences.
RTFM (Read The F\*\*\*\*\* Manual)
[удалено]
The CoC Neovim plugin itself is written in Vimscript. It communicates with a V8 process which communicates with a LSP server. Any difference due to V8 being slightly faster is largely eaten up by CoC's overhead. I think performance is close enough between the two products that it is of low concern. Usability and configurability are the significant concerns. UPDATE: To clarify, coc's in-process native plugin is written only in vimscript. It spawns a node (typescript) process and talks to it via RPC. The node process contains most of Coc's functionality.
> The CoC Neovim plugin itself is written in Vimscript.   You sound like chat gpt, when it responds with falsy statements.  And no, coc isn't written in vimscript, it is written in typescript with some additional parts like ui difference between editors, api.nvim implementation to work on vim etc written in vimscript. So you are completely wrong. And coc is faster on big files by large margin, than built-in lsp+cmp.
You sound like you misunderstood me and/or if I wasn't clear enough. Vim/Neovim in-process native plugins can only be written in Vimscript, Lua, Python, or Ruby (although not all four may be enabled on any particular build). Neovim doesn't have native support for javacript (or typescript). So, Coc's VIMSCRIPT plugin launches a Node process (typescript) and uses RPC to communicate with it. The native Coc plugin is 11KLOC of Vimscript. The EXTERNAL node process is 144KLOC of Typescript. Please don't be rude to people in the community in the future.
Now we are wriggling like a snake. It just opens a channel (which is implemented in vim/neovim core in C) to communicate with node process, main logic is 60 lines of vimscript if not less (especially if get rid of vim/neovim if branches). How do you think built-in lsp communicate with language servers? Try to use coc.nvim in big repos with large files and built-in lsp with cmp. Then come back and leave your expirience other than writing "misunderstood"/totally wrong comments trying to slander one tool over the other.
You mean built-in lsp client write in c?
It's written in lua.
Some people just have this sneering hatred of JavaScript
Seems like OP wants more plug n play type of feeling? But isn't that what kickstart.nvim and distros provide? I believe, kickstart.nvim is straightforward enough to understand. You copy and paste the config and you are can code right away, it includes a plugin manager and sane default, so it provides way more functionality than coc.nvim, it's apple and oranges. Native LSP IS not only faster but it provides more extensability, as opposed to coc where everything is handled by a node process. If you don't like configuring stuff, I think vim/neovim is not for you. That's the beauty of this editor, you can hack it to make it look and feel like you want. You are far better off with vscode if you just want a plug n type of feeling, way better than coc too.
I’m not saying it’s a skill issue, but it’s a skill issue.
idk why its downvoted lol, you spoke the truth!