editor
I have been using neovim for around 4 years now, and I had been using vim for even longer before that. Complaints I have seen mentioned when discussing these editors are that they are not IDE’s. Personally, I think neovim’s method of implmenting IDE features through the plugin ecosystem one of it’s greatest strengths. There has been many times, where I have tried to setup my custom tailored IDE feature in neovim, and found that I was really interested in the underlying technology that this process exposed me to. Further more, the satisfaction of tailoring the feature to behave 100% how I want it to, is something I had never experienced in an IDE. If you are not using neovim, I urge you to atleast try it out. There is plenty of pre-packaged distributions that will get you up and running in a couple of minutes.
While I personally have customized neovim 100% from scratch, since I started using it, I do not have much experience with the previously mentioned neovim distributions.
As previously mentioned, much of my neovim configuration predates the lua api
support. I’ve slowly been migrating my config over to exclusively lua
plug-ins, but haven’t been in that much of a rush to do so. I have moved back and forth between
lua vs vim implementations of plug-ins, so some of the discussion below might be rather niche.
With that being said, I feel as though my experience between bouncing back
between both languages has given me a good understanding of the pros and cons of
each. Below I will try to briefly outline what plugins I find most helpful, and
try to compare them against their alternatives.
neovim lsp solutions
I believe the two largest neovim lsp’s in the neovim ecosystem are the native implementation and coc.nvim. I have used both, and in fact currently use both ( coc.nvim for almost all languages, and the native lsp with nvim-cmp for command mode. The main reason I am still using coc.nvim for standard lsp features over the native implementation is that I find the json based configuration much easier to work with. At the time of writing this, the native implementation is much more difficult to configure for non supported LSP’s. Having built a LSP in the fish language, I found setting up the json based node configuration mush simplier. Below are some of the key points I have found when comparing the two.
coc.nvim
Written in typescript, coc.nvim allows very simple porting of vscode extensions. LSP’s for langauges are also most commonly written in typescript, so bad server versions feel more familiar when both the server and client are written in the same language. The main downside to coc.nvim is that it is slower than the native implementation.
native-lsp and nvim-cmp
In nvim-cmp and the native lsp, newer releases of neovim, allow for bleeding edge features to be implemented faster than they are adopted across other client’s like coc.nvim. However, I have always had issues with schema completions for options to the language server configuration in lua.
tree-sitter
Current neovim releases have a native api for manipulating the syntax tree’s in a buffer that are generated by the tree-sitter parser. This allows for much more powerful syntax highlighting, and a more feature rich tree-sitter experience than the node.js verions of the tree-sitter api. Plugins like tree-sitter-playground are a great example of functionality that the native neovim api provide’s, where as, node.js based tree-sitter implementations are not as complete.
other plguins
- firenvim: insert text editor into browser text boxes (vimscript)
- noice.nvim: pop up textbox for command mode (lua)
- toggleterm: terminal in a popup window (lua)
- windline: animated status line (lua)
- telescope: fuzzy finder (lua)
For more exhaustive lists of plugins, check out awesome-neovim.