Neovim v0.5
github.com
github.com
I used to flip between the two anyway - if I needed a better intellisense for, say, a large typescript project, then vscode won, everything else was nvim. Now I have the intellisense of vscode ontop of neovim.
I haven't tried it yet, but my main concern is that VS Code probably has a lot of keyboard shortcuts (e.g., C-v for visual block mode) that I'd have to reassign, which could potentially be a bit of a pain initially.
Mind sharing any pros/cons you've run into with the Neovim plugin so far?
The only thing I've noticed is sometimes there's a delay on the Esc key detection to exit insert mode. That could be my binding of CapsLock to Esc/Ctrl though (with a combination of xmodmap and xcape).
I'm also a long time vim user but this has made it bearable to use the same editor as the rest of the team (engineers who need to code, not software engineers) so that they understand what's happening when pair programming etc.
By default there are some conflicting keybinds like ctrl-o and ctrl-v, but these can be disabled in vscode settings.json so wasn’t a problem.
The main feature that doesn’t work over the neovim-vscode rpc bridge is undo tree, that was important to me. You also have to put up with much slower start up times and slower syntax highlighting because vscode uses lsp highlighting.
But the deal breaker for me was losing any vim plug-in with a ui component like fzf, fugitive, and the file tree I like (fern.vim).
It might work for you, some coworkers switched from vim to vscode-neovim and were very happy with the compromise.
Also VSCode is much, much more resource hungry.
vscode-neovim is designed for and requires neovim 0.5. I hate, hate, hated vscodevim but vscode-neovim is very good, very usable; I stopped using VSC altogether until vscode-neovim got real. It's not perfect, it still needs work on command mode, but it's quite usable. I even got rid of my other vims (MacVim, VimR, ...).
Editors like Vim, Emacs or VSCode are all about the plugins
I use emacs for org mode And VSCode for everything else, because simply most proramming languages have their main plugins on VSCode
The only way you can move from VSCode to neovim is, if you dont care about the plugins
Why would you VSCode if not for the plugins
They've done it before and they'll do it again.
LSP for MS and VS Code is "come, make our proprietary editor more valuable by supporting languages we can't be arsed to worry about!"
https://github.com/microsoft/pylance-release/issues/4
(I am an enthusiastic advocate for LSP otherwise.)
Truly a valid concern.
IMO TypeScript is VSCode strongest use case - I would use VS code over VisualStudio for example on C# projects when I had to edit fronted parts - it was so much better. IntelliJ TS stuff is the only thing that comes close/is on par maybe and I'm a happy camper in that ecosystem for the last few years.
None of the LSP plugins I've tried with neovim worked nearly as well as they do in VSCode (the few times I tried to spin it up for old times sake).
Can you link me to how to configure that? I have been using LanguageClient-neovim, which is a Rust plugin.
The best place to start is here: https://github.com/neovim/nvim-lspconfig
I use it in combination with nvim-compe: https://github.com/hrsh7th/nvim-compe
but comments above are suggesting that because of LSP (Language server protocols) plugins can be portable now, from one editor to another
i thought each editor needed its own plugin, and VS Code always seem to have the main plugin, didnt really come across plugins that run across multiple editor, but then i was not really checking this, next time i will check it
I really hope they'll do some official work on lua-based solutions for autocomplete and code snippets in the future to really round out the LSP support, if that's something that they want to highlight as a feature of neovim. I still think VS code is the way to go if you want LSP features, but 0.5 is a terrific step forward and everyone who worked on it should be very proud.
Once I added snippets and modified the completion code, the ability to hit "Enter" to select an autocompletion selection broke and I couldn't manage to fix it without preventing the key from entering a newline in insert mode. I ended up just remapping it to a new key. But even then, it's still a little quirky- if I type some text and hit tab expecting to add some spacing, I'd instead get prompted for autocomplete suggestions I wasn't looking for.
I get that all this is fun for some people, but I just want sane defaults that work like VS code.
For example I have to install 3 different plugins to get all the LSP UI so it means I have 3 different opinions on how various parts of its UI should look and it's a real mess--the popups for suggestions as I type are totally different looking compared to the popups to show function signatures (and each has their own bespoke way of being configured).
Which UI plugins do you need? We've done a lot of work leading up to 0.5 in improving the built-in handlers, so you shouldn't need a UI plugin. I think the main plugins people install (in addition to lspconfig):
* nvim-compe (autocompletion)
* vim-vsnip (snippets)
* lsp_signature.nvim (automatically pop up signature window, note signature_help is built-into core, just manually triggered)
Some people use lspsaga.nvim, but borders are already merged into the core handlers (and our floating windows now provide better markdown styling than lspsaga), so the main utility of lspsaga is in the different way of interacting with code actions, which I personally do not prefer.
Anyways, please open an issue or PR if you have concrete suggestions (or start a discussion on our discourse)! I'm personally very invested in improving the UX around the built-in language server client, and it has really improved leading up to the 0.5 release.
Perhaps there are ways to tweak lsp_signature UI... but at this point, I chucked it all and went back to coc.nvim which does it all (suggestions, signatures, etc.) all with the same UI.
Make it like that--make it work with all UI out of the box and not make me dig through tons of plugins. That's my honest suggestion. Sorry I'm not joining a discord, etc. to give this feedback.
Many of our users explicitly don't want automatically called functions that would slow down the editor (autocommands that map signature requests to the language server, for example), so by nature neovim's core implementation is extremely conservative.
One thing I would like to do, is make the automatic pop-ups for signature easier to implement with our current handler, which means a plugin like signature-x could use our upcoming lsp.config option to configure it's borders (https://github.com/neovim/neovim/pull/14681), and match the rest of the UI.
I also have another project I was working on before the 0.5 stabilization phase (https://github.com/mjlbach/neovim-ui). The goal with this is to have composable/overridable UI elements built into core (which we would use for our internal lsp functions), that can be used (or overridden) by UI plugins.
In summary, I think the likelihood of autocompletion (and generally auto-anything) being built-into core is very small, but providing the APIs in neovim core to make snippets - autocompletion - automated UI elements easier for plugin authors is a high priority.
So IMHO I'd love effectively a dial, perhaps the 'distractions' dial. It's not a binary on/off, it's a spectrum. It could be off--nothing at all distracts me (zen mode basically). It might be on a little bit--perhaps just showing current stuff LSP does by default, errors, etc. And it might get cranked up to max--every keystroke throwing more information at me about what's happening, what am I editing, what's related to it, etc. During an editing session I might move inbetween each level on the distraction dial many times. Kind of like zooming in and out as you're editing a photo.
The only thing that pops up by default right now is diagnostics.
Maybe they've never tried or deliberately ignore coc.vim for whatever reason. coc.vim works almost out of the box, has the fastest and most pragmatic maintainer who helps anyone and tsserver makes it as good and as fast as VS Code. Instead of just cloning coc.vim's tsserver implementation—or why do they no contribute to coc.vim??—roll their own inferior solution, years later. It's not that nvim's LSP implementation is at its beginning and we can expect more is coming, no the maintainers just do not know or ignore the status quo. Feels very much like Bram a decade ago.
Maybe it's time that we see a third fork—coc.vim.
We provide a client, not language servers, so we're kinda at the mercy of whatever language servers exist. We offer a configuration in lspconfig for https://github.com/theia-ide/typescript-language-server which wraps tsserver, but there is hope that microsoft could implement lsp protocol directly for tsserver https://github.com/microsoft/TypeScript/issues/39459#issueco... at which point the experience should be more comparable to coc.nvim.
On a different note, we have made upstream requests to MS, worked with language server authors, and generally try to contribute positively to the language server ecosystem. Neovim users will always be free to use coc.
If you have actionable items for improving the client, please reach out on our discourse or on our matrix channel. Thanks!
I've been using neovim HEAD (0.5 pre-release) for a while and it has been awesome. It all started with this config [0] and from there and haven't tried (as before) to join a vim cult but instead to use it as a tool that works for me (i.e. use mouse scroll to browse around, use arrows on insert mode, and other vim sins)
Little by little I've been looking at how I could do something a little better and pretty much every time vim has an awesome way for me to do something! Yanked some text then deleted something but I want to paste the yanked text, not the deleted one? "0p is the answer. Need to replace all ___ but not modify the prefixed numbers? I can use visual regex to easily work that out! I'm doing something over and over? I can make that into a macro! There's a macro that I always use on certain file types? I can make an autocmd to load some string to some macro when I open certain file.
It'a awesome feeling that time I've actually learning about registers, macros, regex, windows, buffers, and everything else in a modern and snappy tool!
This is what I love about vim, there’s always something new to learn.
I use registers often but I admit I haven’t memorized the meaning of the auto-populated ones like 0.
I'm sure it's very well known but the "greatest stack overflow answer of all time" is an example[1] (IMHO obviously :D )
Vim Golf (also well known) is another invaluable and surprising resource[2].
1. https://stackoverflow.com/questions/1218390/what-is-your-mos...
That allows me to see what my regex matches. So I can start typing ^d*\. Hello and that would match any start of line digit followed by a dot and the word hello.
I still have a lot to learn there but just that has been incredibly useful for me.
Hope that makes sense
While LSP is great, it basically came from nowhere in the last couple of years. My concern: what if something definitively better comes along in another couple years, and we're "stuck" with this baked into the editor?
For context, using ALE, I've been able to gracefully migrate my language-specific helpers from pre-LSP to post-LSP universes, over the years as LSP helpers have become definitively better and faster, one language at a time, all without needing to recompile or download a new binary.
I'm very open to the idea that I'm missing something obvious, because I have a lot of respect for neovim and neovim contributors. I understand that neovim is not trying to replace vim but evolve it. This feels like a move away from plugins and into monolith territory, which feels like a big step. Curious to hear other's thoughts.
To be clear, I'm not for or against this, I'm mostly curious about the reasoning / thinking behind this, if anybody has links I'd love to read them.
• LSP means Language Server Protocol [0]
• ALE means Asynchronous Lint Engine [1]
It would be interesting if ALE could integrate with nvim's LSP implementation though, although I'm not sure how that would work.
From my understanding, it’s also an opt-in feature, so you are free to use anything other language client or no language client at all.
But I agree with you that Neovim is gradually becoming more monolithic (though I believe it’s still very snappy and light). I’m pretty happy about it, though.
Sure, it’s worth considering…
> It’s not vim, it uses a shit ton of memory, and you can’t run it in the terminal
You just answered your own question on why it’s not necessarily a good idea ;-)
i've been using vim for 10+ years. i tried vsc with a vim extensions and it's just not the same. maybe it's just because i'm super used to my vim config, but vsc + vim plugin feels so awkward and slow.
My data is purely anecdotal but I've noticed a correlation: people who spend the added time to configure their editor (be it vim or vscode) tend to be better at using their editor. It naturally follows that the time spent configuring it leads to a better understanding (and better recall) of how it works.
In my mind, the big "omnibus" plugin bundles for (n)vim prevent that understanding just as much as a default vscode config does [1].
[0]: Either by adding a plugin or, in most cases, by incorporating what I want into (n)vim's existing systems.
[1]: And no judgement for that -- not everybody has time or patience to deeply learn every tool they use.
For text/file searching there's fzf + rg + fdfind
All these tools integrate with eachother but are already great on their own.
With nerdtree and other alike plugins you lock yourself into building IDE out of vim. With these specialized tools you can reap their benefits even without launching vim.
1) nvim's built in lsp client is entirely in lua and afaik none of it is related to the nvim core. It is not inconceivable to just move it to a plugin but pretty much everyone will have to depend on it. I think for something as powerful as lsp, it might as well be bundled.
2) the built in lsp client in lua is EXTREMELY customizable and lightweight. In fact, a lot of useful features are enhanced or extended with plugins. Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.
3) The people that built the lsp client are extremely passionate about it and have contributed to neovim. tjdevries has some youtube clips and twitch stream clips where he talks about why this is a good idea. One thing that was mentioned during the stream today was that luajit and using libuv / LUV makes you feel like why not write an LSP client in nvim lua.
I personally think since it is so lightweight and since it is all in lua, it's awesome to have. And the next big thing can also be added to nvim base in lua without too much "cruft".
This goes back to my biggest complaint with the vim ecosystem (and emacs has the same problem): no dependency management. Almost every plugin has to be self contained, because if you depend on another plugin, then you need to rely on you users to manually install that plugin.
However one thing I wish emacs packages had was the ability to version dependencies. Right now you can get a broken plug-in because the upstream package introduced breaking changes.
Also I'm just too old to learn the whole Lua API.. That's not something I hold against nvim, but it's a reflection on my laziness? I just want a good vim based experience and nvim did that for me.
Btw, I paid for Onivim2. Was surprised by its snapiness but it's pretty useless as a working editor if you want equivalent features to nvim
how would you compare to nvim? i tried vsc with a vim plugin and it was just... painful.
Onivim's vim emulation is great.. Because it's literally using libvim. It's also very snappy. But thats where the advantages end.
Well if you are used to IDEs that also had that kind of lag...
I'm surprised to hear this take. I've been a Doom Emacs user for a while, and while it was a bit more elbow grease to get it running on OSX, it was generally worth it for the speed/flexibility...
until
I ran into a non-trivially large Terraform code base. Slowed.to.a.crawl.
On the other hand, even with multiple plugins, VSCode was(and continues to be) very snappy. Nearly instantaneous search and motion.
I'm sure at least one time spacemacs was partly to blame (aka ALL THE THINGS activated/installed) - but it's definitely a difference in "feel" where (Neo)Vim feels closer to vi, and emacs feel closer to vs code/Atom.
Did you ever spend any time debugging what the issue was by any chance? Even with lsp enabled, I wasn't very impressed with any of the features it gave me (emacs or even in vscode)
I'd mirror your comments, and especially emphasize the speed aspect. (I think your ordering of comparisons matches the ranking of differences).
I don't consider LSP to be a monolith. You still have the decentralization of language server development. Rather, LSP is just a standardization of what we have come to expect from editors interacting with plugins. And because the standard is modular in its features, the barrier to entry for new language servers and editors remains low.
As a standard, I don't think LSP encourages monopolization the way that the web does for browsers.
Yeah, perhaps this does make neovim more a monolith, as there are already great plugins like coc.nvim that can be used. However, I believe the expectations of a modern text editor have been raised sufficiently in the last few years that we now expect to have code intelligence baked in, just like we came to expect baked-in syntax highlighting decades ago over editors that lacked it back then.
And given the extensible core of neovim, if a better LSP-like system comes along someone will build a plugin to integrate it. Before this native LSP support there was (and still is) an excellent vim/neovim addon coc.nvim that adds LSP support using nodejs as a process manager for example.
LSP is very anti-monolith by design. Each language has its own little microservice LSP server that communicates to the editor using json-rpc. Everything can be swapped out and replaced dynamically--nothing is linked together or a direct dependency.
Plus, the rest of the application is becoming increasingly modular, not less so.
LSP is not going anywhere. Nor has it been here just for a "couple of years". It's here for over 5 years already.
For people that are interested in knowing more, neovim is having a release stream on teej's twitch channel: twitch.tv/teej_dv.
Strike that, not entirely true: there was one good post 37 days ago, "Neovim is overpowering", that I liked a lot[1].
[1] https://crispgm.com/page/neovim-is-overpowering.html https://news.ycombinator.com/item?id=27291302
What's the solution?
I love neovim and have been using 0.5 for 1/2 a year now, loaded up with all the bleeding edge LSP, treesitter, etc. stuff and I have come to the exact same conclusion. The ecosystem is just a bit too immature and fragile right now with tons of still-evolving things. The quality of each LSP varies wildly and it's a huge wild west right now figuring out the 'right' way to move configurations to lua, use a package manager for plugins, etc. You're left with a weird frankenstein state of half your tools and plugins in the new lua world, half still in the old world.. and a net loss of features and functionality as stuff is abandoned or changed in the process of moving. It's exhausting to keep up.
LunarVim will be like Spacemacs/Doom Emacs/SpaceVim, but for neovim. A distribution of useful neovim packages with sane defaults.
This project is still at its early stage and many things change rapidly. You currently cannot easily keep your custom changes in sync with LunarVim, but support for this feature is on the way.
In a few months this project should be stable enough for typical users.
` vim.api.nvim_set_keymap('n', '<S-TAB>', ':bprevious<CR>', {noremap = true, silent = true})`
to
`nnoremap <silent> <S-TAB> :bprevious<CR>`
Why convert every single line of vimscript to a noisier lua statement?
The Packer manager seems a step back from vim-plug. Your configuration file is no longer the source of truth. Packer uses a global site directory for plugin as opposed to a local directory like vim-plug. Guess what? Neovim, paq also uses that directory. It's like the old days of plugins of installing everything globally. I had to do this after making a configuration change: :PackerSync, exit neovim, delete cache file, restart neovim, :PackerCompile. Believe me, forgetting a step has been an endless source of frustration.
function bindKey(mode, keys, command, options)
options = options or {noremap = true, silent = true}
return vim.api.nvim_set_keymap(mode, keys, command, options)
end
bindKey('n', '<Tab>', ':bnext<CR>')
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.
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...
* 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
$ 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
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.
The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:
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?
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.
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.
Congrats on 0.5, another release that looks great!
Neovim doesn’t have such incredible and almost ridiculous power to change itself like emacs does with elisp since vim is still not written in lua, lua is just used to access its api, but that api is quite extensive. So, maybe? Hopefully?
https://github.com/asvetliakov/vscode-neovim
This extension integrates neovim into the VS Code environment by mapping keystrokes from VS Code to the neovim binary. This approach (which requires 0.5) is much simpler and more robust than attempting to emulate all of VIM, as the VSCodeVIM extension does.
BTW, I ran into too many corner cases where VSCodeVIM's emulation broke down.
brew update; brew upgrade
...
==> Upgrading neovim
0.4.4_2 -> 0.5.0
... Lua remote plugin host
Lua user-config: init.lua
Treesitter syntax engine
LSP client for code navigation, refactoring
Extended marks (text properties, decorations, virtual text)
[0]: https://github.com/leafo/moonscript
The amount of things you can with just few keys is just phenomenal.
It does have a learning but once that’s achieved you’ll be very much productive and get things done very quickly
Sure we can do same with Neovim, it's just I don't like memorizing every possible commands. It would be great to have a command that lists all the available commands in Neovim along with some description and fuzzy finding just like in VSCode and Sublime.
Both the fzf.vim and telescope.nvim plugins provide a fuzzy searchable list of commands; `:Commands` and `:Telescope commands` respectively. The built-in commands have a description but commands from plugins usually just show it's definition.
Now tweaking vim to the behavior I want is no longer learning an obscure language but figuring out what is the behavior I want and coding that using lua and the vim api. With the lua language server vim’s api is very discoverable!
Now what's starting to happen is that the plugin ecosystems are diverging. Subjectively, it seems like plugin developers are significantly more productive working in languages that are not Vimscript. Accordingly, Neovim seems to be accumulating more sophisticated IDE-like plugins, and this appeals to me on a personal level.
Now that the remote plugin and Lua APIs (including Tree Sitter and LSP!) are somewhat stable, I expect this productivity and divergence to accelerate. I feel like Neovim will be approaching Emacs "power parity" in the next few years, and that's a very exciting prospect to me.
If someone knows a way to install a version of neovim that does not need OS deps...
https://github.com/neovim/nvim-lspconfig#keybindings-and-com...
dwarfs my .vimrc
For complex things, it's nice to be able to do this. But the benefit of having a built-in client is that it works out of the box. This looks like it requires more configuration than many of the existing (n)vim lsp clients, even for the most basic thing: setting up the keybindings.
I spent months trying to mould Neovim into an IDE-style environment I could love (people seem split about whether Neovim should be an IDE or not, but it feels like it’s evolving in that direction).
I tried Doom Emacs because of the buzz around it, fell in love straight away, and built my own Emacs config from scratch to get a better understanding of Emacs (I like Doom, but I found it hard as a new Emacs user to grok the separation between Emacs/Doom/external packages; the appeal of Emacs for me is to shape the tool to your needs and to understand what the packages you’re using do and how to tweak and customise things).
Neovim is improving but it still falls short of Emacs by far in my opinion. Some things to be aware of from my experience of both environments:
Neovim UI is inconsistent. With Emacs I can have every package use Ivy for item filtering and selection, for example, where as Neovim plugins often end up inventing their own UI because there’s no real UI standard in the Neovim space. Even Neovim packages that build good UIs (telescope) feel buggy and laggy to me compared to Emacs equivalents. (I had a persistent issue with telescope where trying to close the popover would take multiple attempts or not work at all).
Package quality is _so_ much better for Emacs. I tried a bunch of different Vim/Neovim git plugins and none of them are close to magit. When I ask Neovim users what they recommend for git integration, they suggest plugins that don’t hold a candle to magit (fugitive), external CLI tools that aren’t integrated with Neovim (lazygit), or say something like, “just use git on the CLI via tmux or iTerm tabs! Vim isn’t supposed to be an IDE on its own - you compose Linux tools in isolation into an IDE”. That’s fine if you embrace that mindset, but I find it unsatisfying now that I’ve used magit for some time. It’s a similar story for pretty much every IDE problem space (projectile and Cider are so much better than their Vim equivalents, for example).
Documentation quality is generally much better with Emacs, particularly when writing plugins. (Lua APIs are documented for Neovim but not to the extent that Elisp functions are.)
Emacs Lisp is also so much nicer to work with than Vimscript and Lua. The ability to run expressions in the environment without reloading whole files or restarting is a superpower, especially when making plugins.
I don’t mean to crash the Neovim 0.5 launch party here – by all means try it! Just be prepared to trade some of your Windows speed-related frustrations for general UX/UI/polish pain points instead. :-)
I agree with you that Emacs and Neovim are at different levels of maturity. And I agree that Neovim could eventually gain better docs, more mature and stable packages, more consistent UI conventions, a better Lua dev experience, less experimental and more actively developed GUIs for those who need something more flexible or accessible than a terminal-drawn UI, better filter-pickers, better documentation for LSP integrations, better git integration, better GitHub/GitLab/forge integration, better plugin dependency handling, a better governance story, a healthier bus factor and contribution story, and more thought about the impact of a fork on the Vim community as a whole.
What I disagree with is the idea that “Neovim will be just as good or better than Emacs in a few years and all your current qualms will mean nothing then” is a compelling reason to use Neovim over Emacs today. My list above is a lot of work, and that’s just to reach parity with Emacs, which will also be maturing and improving in that time. To exceed Emacs for me Neovim would need to do all of that and more, or all of that but better and faster.
I don’t doubt that Neovim will get better really fast because the velocity so far is strong. But right now Neovim feels like a scrappy collection of hacks and experiments from a community of enthusiastic prospectors and beta testers who collectively seem to have no common opinion about what they’re even hoping to build (some still feel that Neovim should not become an IDE or that as much functionality as possible should be shelled out to CLI dependencies).
It’s exciting to be part of a bleeding edge editor community if you’re happy to write or contribute to plugins and try out and configure a bunch of existing ones every few months. It’s less great if you want stable IDE-like features now that feel like they were designed with taste and consistency and have been maintained with love for years.
I don’t really have a horse in the race except that I spent a _lot_ of time configuring and building things for Neovim while using it as a daily driver that I now wish had been spent on Emacs instead. I’m also excited that we have such strong communities of Neovim and Emacs hackers today that both are fun to hack on, get work done with, and continue to argue about with strangers on the internet.
Healthy communities are diverse not homogeneous. You get tunnel-vision if everybody always do things the same way. I use vim on all my servers. I tried neovim awhile ago, but found that muscle memory kept typing vim instead of (nvim/neovim whichever the program executable name is), so I made an alias and tried that for awhile.
I want to use/learn emacs too but never seem to have the time.
But the best engineers can only be about a handful, everyone cannot be the best. That's not what the best means.
It just so happens that of those best, which by the time you get to my age might only be about 3 or 4, they all seem to use neovim.
Generally I rather advise we not do this!! This is a baiting question & one built around superficial narrow-dimensional assessments of "best". But sure, Friday, I've got summer hours: why not write a little homage to what I think is compelling & makes vim such a life-long joy to ongoingly immerse myself into, let's talk some about why I think vim makes some users feel unmatchedly free in a way they would never put down:
Vim's origins as the most user-hostile text-editor known to man (ed) is an interesting origin story. Ed excelled at automation, at writing little scripts to modify programs, in a non-interactive fashion.
This excellence as an automated text editing system stems, in my view, from Ed/Vim's notion of Text Objects, ed/vim's way of telling the editor about where you want to go/what you want to select in a file. The editor as a bunch of buffers (opened files), named registers (which is basically a 1-dimensional (many points) rather than 0-dimensional (point) clipboards), text-objects that can select spots in buffers ("lines 4-7", "the first two characters of this line"), and commands that can be run on text-objects is an incredibly powerful set of general purpose abstractions for doing any variety of text processing task, and there's a nice break down of responsibilities for what does what in this system.
The shake out is cool. Macros in this system are nothing but a stream of commands dropped into a register, with the ability to replay that stream: it basically didn't require adding anything to the existing system to get macros in vim, because vim was already text-driven enough by it's nature.
Text-objects[1] deserve some special mention as a standout component of this system. They are an incredible leap, giving us huge expressivity when we want to cite or reference some part of the screen.
I've always called vim "spellcasting on the fly", as in the ability to combine a bunch of ad-hoc text-objects & commands , but the irony is that it's origin, ed, while yes sometimes used for interactive editing, was quickly primarily used for automation, for rote processing. It's about building a sophisticated model of being able to reference a spot in a document, possibly as the document changes around you over time, & doing certain things. The rote-based/automated use of ed is so core to vim's magic: the power of text-objects to cite specific things on the page, in a endless variety of ways, and then to issue modifications & updates to these powerful text-object's you've named is a wonderful combination of powers, for both rote/automated processing, and on-the-fly/interactive processing.
Vim is far & away the most interesting model of text-editing there is. There are countless editors out there, with wonderful features, and great integration, but by george you just cannot beat (rather, we have not beat) the power of having a sophisticated powerful expressive model for what text is, and how to get to parts in the text, that vim brings. If you want a way to edit text that let's your brain be free to express how to move through & talk about text, that has powerful scripting to let you build & extend your palette of commands, (neo)vim is unmatched.
Epistemic status: 0.2, unresearched, probably a lot of disambiguation/clarifying needed, some liberties taken with the timeline of when exactly what happened.
[1] https://blog.carbonfive.com/vim-text-objects-the-definitive-...
Seriously though this is cargo culting and is a bit silly.
I've used vim/neovim since the late 90s and think I know it pretty well. I don't fool myself that it has any bearing on developer ability.
Any job where where I've had the power to set tooling standards I've strongly pushed for build processes that allow developer freedom to choose any editor/IDE they want.
Most editor/IDE advocacy I've seen, like saddle choice on a bike, comes down to personal ergonomics.
Weird comparison to draw, but like systemd comes to mind. I love systemd so much. It's many different utilities all have a pretty consistent way to be operated & they're all optional & independent, so it's really more of a mono-repo. My warning hazards have never gone off on systemd: the init system is radically better, building a suite of tools using the same design system makes it so much of a joy; there's consistent powerful strategies I can deploy when working with any of the systemd monorepo daemons.
By compare neovim intuitively feels a little more integrative to me, more monolithic rather than being so strongly mono-repo'ish. Neovim scripts will emerge hooking into, extending, embracing these new integrated plugins, the community will continue to interweave themselves with these features. Trying to change things latter will be harder than it would be with systemd, there's more of a Big Ball Of Mud[2] fear here for me. My concern is probably about ~0.2 on the unit scale, and my ok'ness is probably ~0.6, some in between neutrality, so I'm not trying to say this is bad oh no. But I think there's some value to the comparison.
Anyhow. Language Server Protocol is the shit. It's the primary channel for how we turn text-editors into Integrated Development Environments. Taking nvmim-lsp & integrating it is a huge step for this project.
There's also some new hooks for Lua to work with, which promises ever better scripting: that seems like the one core enhancement to Neovim proper in 0.5.0.
[1] https://crispgm.com/page/neovim-is-overpowering.html https://news.ycombinator.com/item?id=27291302
vim is bash. nvim is zsh if not fish.
Or maybe vim is RHEL, and nvim is Fedora
Vim has been bundling plugins since forever. Netrw, for example, is just a bundled plugin, but also a bunch of others like matchit.
This is an implementation detail IMO. Firefox also implements some of its functionality via extensions: screenshots, picture-in-picture, and various web compat hacks are all extensions. Most people don't even know and couldn't care less.