I thought switching from vim to neovim would be like switching from a nano+ to a VSCode CLI, but it’s far from that. There are so many plugins and it’s not as easy as declaring which plugins I want, having one dictionary/mapping/attribute set with keybindings, another with global preferences, and done.

Then there’s something about language servers. The list on https://github.com/rockerBOO/awesome-neovim is daunting. I thought LSP support was built into nvim. Why are there so many LSP plugins? And what the hell is treesitter and why do I need it?

I copied some dude’s config and suddenly Ctrl+P for completion didn’t work like in VIM.

There’s just so much unexplained jargon and abbreviations, that it feels like I have to read neovim code before even using it (ain’t nobody got time for that). Is neovim actually the right tool to use to have an easy CLI IDE? Is there an easier command-line alternative that just lets me go “oh, this language isn’t supported, let me open the package manager and install the $language-plugin”, with “Goto Definition”, debugging with breakpoints, code formatting, refactoring (rename variable/method/class, extract function, etc.) ? Maybe neovim just isn’t the right tool for those without years of time.

Edit: Thanks for the suggestions everybody. Finally went with Lunarvim and it’s been a joy!

  • @zygo_histo_morpheus
    link
    1
    edit-2
    9 months ago

    You’re propably better of not worrying too much about the awesome-neovim list until you’re more familiar with nvim itself

    I thought LSP support was built into nvim. Why are there so many LSP plugins?

    Most of the plugins seem to be adding bells and whistles to the core LSP functionality and can be safely ignored. The main one that I recomment is nvim-lspconfig which makes it easier to get servers up and running. Neovim itself knows the lsp protocol but isn’t aware of any particular lsp servers. lspconfig comes with premade configurations for different servers so that you don’t have to e.g. tell neovim where to look for the executable or which servers handle which filetypes and so on. It is doable to use LSP without this plugin as well, it just means more boilerplate in your config file.

    And what the hell is treesitter and why do I need it?

    Treesitter is a different way of parsing files for e.g. syntax highlighting. Vanilla (neo)vim uses a pile of regular expressions to perform syntax highlighting essentially, while treesitter actually parses the source files in a way that is aware of the way the target language works. Treesitter might know the difference between a macro and a function for example, and can highlight them differently. You can also querry the syntax tree that tressitter has parsed for use in custom scripts or plugins. Also completely optional unless you want to use a plugin that depends on it.

    As for plugin manegement, I use vim-plugged (which is a vim plugin but is also compatible with neovim). You basically just list the github/gitlab repos you want in your .vimrc file and run a command to download/update them.

    My lsp code in my init.vim file is as follows (taking advantage of nvim-lspconfig): https://pastebin.com/0Wy1ASwk. Adding a new lsp means making sure that the server itself is intalled (e.g. through my package manager) and then adding another line in the langs object, like when i added erlangls i just added erlangls = {}, on line 19.

    (EDIT: For some reason the nmap('gd', vim.lsp.buf.definition) line is repeated a bunch of times in the paste bin. That’s not on purpose)

    Debugging is imo a weak point for both vim and neovim, there’s nvim-dap and vimspector which takes advantage of LSPs sister protocol DAP (debug adapter protocol). Setting it up is principaly similar to LSPs. Vim and neovim also have the builtin termdebug plugin which you can load using packadd termdebug in you .vimrc file and allows you to debug using GDB.