My favourite new thing is actually tree-sitter. Currently it’s being hyped for better syntax highlighting (which is nice), but I’m most excited about defining text objects on language constructs. I really don’t like trying to shoehorn words, sentences and paragraphs to deal with parameters, scopes, functions etc. Having language-aware text objects for these is really neat.
I don’t think it’s anything that would be impossible to get working in Vim, but being built-in is pretty nice.
This plugin sets it all up and has some examples: https://github.com/nvim-treesitter/nvim-treesitter-textobjec...
The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:
As an example of why I love Lua support, I wrote a small file finding plugin for myself because I wasn't satified with the many alternatives (not a huge fan of fuzzy-matching). It took only a couple days to have a working plugin, and it has been fun to extend it with new features over the last month. The Lua API is relatively straightforward, and it really lowers the bar for writing plugins and small helper functions to add to your config.
Switching from Vim is not necessary, but Lua support alone was enough to convince me to give it a try, and is the main reason I have stayed with Neovim.
I'm probably a bad neovim reviewer though since I'm not really keen to try the LSP stuff. I wind up working in a lot of different languages and inevitably I feel like getting accustomed to completion working well in language A only to have it fail with B is more annoying than having no completion at all. I'm curious whether I'll wind up using anything which is only possible in neovim.
* ease of getting started. nvim is just vim, you can bring over your vim config and it'll just work.
* integrated lsp. you could have vscode like auto completion natively
* tree-sitter. google it to believe it
and much, much more
After Googling I have no idea what it is, it's a parser but for what? Syntax highlighting? That doesn't seem so impressive
Yes, but it enables many tools to cooperate on highlighting/"understanding" synntax.
Except when it doesn't:
$ nvim init.vim
Error detected while processing /home/martin/.config/nvim/init.vim:
line 44:
E474: Invalid argument: completeopt=menuone,popuphidden,noselect
line 50:
E518: Unknown option: completepopup=highlight:Pmenu,border:off
E824: Incompatible undo file: /home/martin/.cache/vim/undo/%home%martin%.config%nvim%init.vim
Or when opening a Go file: $ nvim a.go
Error detected while processing function edc#init[34]..<SNR>66_apply[40]..<SNR>66_save:
line 8:
E121: Undefined variable: v:none
E116: Invalid arguments for function get
E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
Error detected while processing function edc#init[34]..<SNR>66_apply[32]..<SNR>66_save:
line 8:
E121: Undefined variable: v:none
E116: Invalid arguments for function get
E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
Error detected while processing function edc#init[34]..<SNR>66_apply[2]..<SNR>66_save:
line 8:
E121: Undefined variable: v:none
E116: Invalid arguments for function get
E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
Error detected while processing function edc#init[34]..<SNR>66_apply[14]..<SNR>66_save:
line 8:
E121: Undefined variable: v:none
E116: Invalid arguments for function get
E15: Invalid expression: get(b:edc_save, a:setting, v:none) isnot v:none
Error detected while processing function gopher#go#set_build_package[11]..gopher#go#module:
line 12:
E117: Unknown function: chdir
And they don't even always show properly on startup (just "press ENTER", need to use :messages).There's loads of incompatibilities; some behaviour is different as well. I can't get it to stop clearing the terminal on exit for example; my 'nnoremap <Leader>p "*p' mapping just inserts '"', my Control+space mapping doesn't work for whatever reason, for some reason a lot of stuff looks different even though it has the same colour scheme, quite a number of my custom functions/commands/mappings error out for various reasons, etc. etc. And not all of these are very complex either: <C-Space> is a simple expression map: inoremap <expr> <C-@> pumvisible() ? "\<C-n>" : "\<C-x>\<C-u>" – Pressing <C-x><C-u> works, but this doesn't(?)
"You can bring over your vim config and it'll just work" might be true is you have a simple vimrc with a few basic ":set"s, but it breaks down very fast.
At this point, I think it's probably better to see Neovim as its own editor rather than "an improved Vim". Obviously based on Vim and still with close ties (many Vim patches are still backported), but the "it's just like Vim but with async + true colours"-days are long gone, and the differences will only increase in the future.
Personally, I even stopped making my plugins compatible with Neovim. For example methods ('foo bar'->split(' ')) aren't supported, but were added to Vim close to two years ago (Aug 2019). It's not that the Neovim people are against it: just no one bothered to port it as they prefer to work on the Lua stuff. I find it very convenient so I use it, and Neovim users... well... Sorry :-(
As an inveterate vim user, I jumped to neovim in hopes of a leaner, meaner and faster editor with an easier configuration process ( i don't like vimscript as compared to emacs lisp). After 5 years, neovim has hit a lot of milestones and I see it going places, yet the only thing that still attracts me to it is the energy and enthusiasm of the community.
I still don't fancy learning an entirely new language to configure my editor, but that's the fun part! ymmv I guess.
Neovim may well be taking the right approach. Capture by existing users has its own costs. But we should be clear-eyed about its intended audience.
1. Development model (vim=Bram, neovim=communitiy of people) 2. Movement to a more accessible language for writing plugins
Now, pretty much any programmer can read a lua program, and it takes about an hour to learn, whereas I think the most flattering honest word anybody has ever used to describe vimcsript as is 'pathological'.
For the second kind of person, vimscript is like some combination between russian roulette and vogon poetry, bomb defusal and surreal nightmare. For the first kind of people - I don't know, there are probably some upsides, but honestly, who does that? Do you? That's what you have to ask yourself.
And more, if you're not that kind of person today, do you want to become that person?