I love Neovim. I switched from VSCode and never looked back, it's just so much more efficient to just do everything with your keyboard. In case someone is interested how to do the things you're used to from VSCode, I created some videos: https://youtube.com/playlist?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...
Funny, I switched from neovim to VSCode + the vim plugin. Sure, it doesn't have everything I would do with vim supported, but it's enough and overall it's a better experience
I've started using the vscode neovim plugin. It runs a headless neovim in the background so you get literally everything that both editors provide in one. It's not 100% flawless but it is damn good.
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.
As a LONG time Vim (now Neovim) user, I've been pretty curious to try this as it would allow me to retain some of my beloved plugins and custom config without the effort of trying to find replacements or reproduce my config stuff. I imagine I could also get rid of most of the language server / autocomplete / code navigation type stuff that comes easier in VS code. It could potentially be the best of both worlds if it's done as well as I'm hoping it is.
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?
I've been using it for a couple months now. It's really quite good and the plugin disables most (all?) of the clashing hotkeys.
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.
I started with vscode but moved to (neo)vim 2 or 3 years ago. Last year I experimented going back to vscode with one of the vim plugins.
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.
I tried switching to VSCode with the vim plugin. but I got frustrated with vim keys that didn't quite work right on VSCode. And iirc configuring custom vim-style bindings was quite a pain. And then there were the neovim/vim plugins that I used that didn't have good equivalents in VSCode, especially that worked well with the vim plugin.
You were probably using the more popular vscodevim with its 2.7M installs. Try vscode-neovim with its merely 93K installs.
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, ...).
Regarding programming languages, the answer is the language server protocol (LSP), an editor-agnostic way to use IDE-like features, originally developed for VSCode. Works for both Neovim and VSCode (and many others). Somewhat ironic that one of VSCode's best inventions is the one which made me switch away from it.
I just switched from 0.4 to 0.5 specifically for LSP and treesitter support. There is zero difference between it and vscode for me now. Neovim 0.5 is a game changer and closes the gap between it and vscode.
I saw it as Microsoft's signalling that they care more about being in the good graces of the wider developer community than about dominating the programming editor/IDE market. After all VSCode is free. I'd argue that giving away VSCode, LSP, Monaco (the base editor) and so on has been a successful means of redeeming their brand in the eyes of developers and really anyone who ever touches code. That could backfire if they took on an aggressively competitive stance. Letting LSP play nicely with other editors seems therefore good business for them. It also appears that as a profitable business, money Microsoft spends on VSCode might otherwise be spent as taxes?
If I am up to date TypeScript doesn't actually provide LSP and the 3rd party implementation is a wrapper around TS language server custom protocol and is worse in comparison. (They have/had plans to change this but it's been years since I saw the issue raised and not much progress from what I saw, haven't checked in last couple of months since I'm no longer in TS space)
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).
Well, mostly of the language specific plugins are language server protocols (LSP), you only need a client to make they work on any editor, I used to use CoC on vim to have that power, but now with the new version of NeoVim the client is build-in, so...
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
It's not that plugins are portable. LSP allows any editor that supports the protocol to provide language support (using a backend "language server" that is editor-agnostic), so it is not that hard for most editors these days to provide good intellisense/syntax-highlighting etc. that used to be limited to commercial-grade IDEs.
I'd love to go back to (neo)vim. I like vscode fine, but sometimes it sounds like a rocket is taking off from my laptop. However, the ability to have a full remote development environment act pretty much exactly like the local one is the absolute vscode killer feature. I just can't go back to a ssh season, cloning the plugins, and dealing with occasional latency.
I've tried VSCode a couple of times but I always go back to Neovim. VSCode still depends on the mouse and that kills it for me. I haven't found anything I can't do in Neovim actually. I have a nice setup with Tmux and being already in the terminal is just too convenient and fun.
In my experience, the built in LSP is a mixed bag. Getting language servers configured is a breeze, diagnostics and go-to definition work just fine. But trying to get autocomplete and snippets to work is an exercise in frustration. There's a handful of different hobbyist implementations which are all somewhat-maintained and somewhat work together but it's buggy and you end up needing to do 20x the effort of using VS code to get not quite the same ease of use.
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.
Agreed. It took me half a day and I came not remotely to the UX and performance of coc.vim. Most incl. the nvim team are not aware that eg. tsserver is the fastest and most responsive code formatter for TS (yes, it goes beyond the LSP spec but that's how it is, also for historical reasons). Prettier does not come close.
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.
Hi, I'm a maintainer. I think this is a huge mischaracterization of the team. We definitely are aware (and inform users) the current state using the theia wrapper lags coc.nvim and vscode. We've never said anything disparaging about coc.nvim, and the built-in client is still seeing rapid development.
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 didn't have issues with compe until I started using snippets, at which point I needed to manually modify the lua code that they provide for you (to own and maintain yourself) for tab completion. I had to spend a fair amount of time getting the right compe - snippet provider setup that would populate correctly.
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.
I have a question. Once you hit the tab and get a list of completion items through either completion-nvim or nvim-compe, how do you further narrow down the list? All I can do is cycle through items or match by prefix, but I want further narrowing by matching substring/regex/flex anywhere in the items à la Ivy/Helm from Emacs (or any of the so many completion systems available in Emacs).
Yeah coc.nvim is a much better experience in my usage. I want to love the native LSP, but the hodgepodge of in-progress or abandoned completion, suggestion, signature, diagnostic, etc. UI is a big pain point right now.
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.
I tried nvim-compe, but it explicitly doesn't support signatures (see https://github.com/hrsh7th/nvim-compe#does-not-work-function... ). So I installed the recommended lsp_signature.nvim and it's a bit of a mess. The UI for lsp_signature has enormous borders and doesn't match at all with the rest of compe.
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.
I understand the frustration (making neovim more cohesive is definitely a goal). It sounds like coc provides the UI you are used to, so there's no harm in sticking with that!
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.
If we're just spitballing thoughts, I'd like something that's kind of the opposite of zen mode. I don't always want signatures and completions and things binging and bopping and showing me suggestions--if I'm working on a codebase and language I'm fluent in then all of that gets turned off. But if I have to pick up some under-documented massive codebase where everyone just uses VS code/intellisense--I'm going to need all the suggestions.
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.
That's an interesting idea! It's for sure possible, it would just take some conditionals/functions to reset diagnostics in your init.vim/init.lua. I personally turn off virtual_text in my private config. I think our current APIs already facilitate this, so I'm happy to answer questions on our discourse or on matrix about how users can do this.
The only thing that pops up by default right now is diagnostics.
For those out there trying to "learn" vim, give neovim 0.5 a try!
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!
Wow, I’ve been a vim user for like 8+ years and didn’t know about 0p even though I run into that problem all the time. I had even re-bound yank/paste to use a different register. Thanks for the pointer!
This is what I love about vim, there’s always something new to learn.
To be perfectly honest I'm regularly surprised by techniques I don't know using plain old vi let alone Vim/NeoVim. That's still useful for situations where you only have say busybox vi.
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].
LunarVim has a "show b̶u̶f̶f̶e̶r̶s̶ registers" plugin enabled so when you type " it brings up a window showing the contents of various buffers, so you can eyeball it rather than remembering.
Oh, just realized I misread the original comment. I ignored the “, so I thought they were saying you could just use 0p (on my phone, otherwise would’ve tested it in vim).
I use registers often but I admit I haven’t memorized the meaning of the auto-populated ones like 0.
Tbh, that’s how I call it but it’s just having incremental search enabled. That will highlight search/replace matches and the using s/<thing to search for>/<thing to replace it with>
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.
Yes, thanks. That's not what I thought you meant, but it suggests a great idea: Something that gives visual feedback as you construct regexes. I'm not sure that incremental search isn't sufficient, however.
That's exactly what NeoVIM supports: you get a live preview of searches and replaces. The behavior can be enabled with ":set inccommand=split" (preview in a separate window) or ":set inccommand=nosplit" (inline preview).
Is anybody else uncomfortable about the idea that an LSP client is now baked into the editor (as opposed to being a plugin)? Are there big performance gains to this approach?
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.
I'll give you my perspective (I'm just an average user):
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".
> Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.
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.
Emacs does not have the same problem. When you install a plug-in it will install the dependencies as well.
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.
Emacs nowadays have package management. And doom emacs is even better in that, because the management is declarative (you have a file with all your packages and it installs them and their dependencies)
ALE is amazingly useful even for curmudgeonly old timer Vim users. My one gripe is that I want the warnings to disappear once I begin modifying the buffer, which I have achieved. Can post the relevant part of my vimrc if desired.
I also use ALE, and my main reason not to switch is that I also want to run linters, and I don't want to install a separate linter plugin when I know ALE works just fine for me.
It would be interesting if ALE could integrate with nvim's LSP implementation though, although I'm not sure how that would work.
I have been an nvim user for the past few years now. I tried the whole modern nvim experience with Telescope, built in LSP and other Lua based extensions.. My conclusion is that my current setup with Ale, FZF + silver searcher, clangd/pylint and Deoplete is way faster, less buggy, albeit harder to setup.
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
VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor. The vim emulation is a joke.
Onivim's vim emulation is great.. Because it's literally using libvim. It's also very snappy. But thats where the advantages end.
> VS Code is an awful editor in general. I don't understand how it's so popular. Maybe it's just me but I don't like having 300ms lag between every action I perform on my editor.
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.
FYI the few times I've half-earnestly tried emacs+evil one of the reasons I've gone back to (neo)Vim is that emacs feels sluggish.
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.
Doom emacs has a focus on speed that spacemacs just doesn't have. It's similar enough to spacemacs that it is easy to pick up if you got used to spacemacs at all. I'd recommend trying it out and see how it feels.
I spend well over half of my time in Terraform repos. I've also noticed doom emacs slowing down considerably whenever using the terraform-ls so I have lsp disabled for terraform.
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)
> This feels like a move away from plugins and into monolith territory, which feels like a big step.
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.
It's not enabled by default, you have to install language servers and turn them on one by one.
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.
I would actually LOVE to see VIM with NerdTree, File/text searching, lsp and first class git support baked in and integrated well without need of tuning something in your .vimrc file every weekend.
I know it sounds snarky, but at some point of vimrc complexity it’s worth considering just switching to vscode with the vim extension. It can use neovim as a back end and you get mountains of features out of the box. I created vim-idiomatic key mappings to all the vscode features and extensions I commonly use. It’s not vim, it uses a shit ton of memory, and you can’t run it in the terminal, but I love it. For context, I was formerly a vim snob for 10 years. I’m also mainly a typescript guy so YMMV.
I don't see this often talked about, but some of the biggest value that (n)vim provides for me is that I've configured it myself. I know what's in my .vimrc because I'm the one that put it there. It takes me longer to add new features [0], but once it is set up how I want it, I understand it more deeply.
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.
>I know it sounds snarky, but at some point of vimrc complexity it’s worth considering just switching to vscode with the vim extension.
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.
Another nice aspect of Neovim 0.5 is that you can do the entire configuration in Lua, so you can break out your config into multiple files and have things more organized and compartmentalized.
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.
I actually started using Neovim builds from master to get access to built in LSP before this release. It’s faster and lighter weight than any other LSP client I’ve used (I have used vim-lsp and languageclient-neovim in the past).
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.
>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?
LSP is not going anywhere. Nor has it been here just for a "couple of years". It's here for over 5 years already.
I've been using neovim since the initial fork. The Neovim 0.5 is by far the most impressive milestone yet. I tried it couple of months back (before release) and immediately jumped to support the developers through the Github Sponsors after trying it out.
I'm excited for this release! Built in nvim-lsp, treesitter support, better support for accessing vim internals from lua are all awesome additions. I've been using the nightly releases for a while and it has been great! I'm looking forward to seeing the larger community now have access to the stable release!
For people that are interested in knowing more, neovim is having a release stream on teej's twitch channel: twitch.tv/teej_dv.
I went back to coc from nvim's native lsp. I think the nvim lsp world needs another year to stabilize and mature. The default lsp configs are pretty rudimentary and make big assumptions like every project root is a git repo. You can't easily just have a project specific LSP configuration file like you can with coc. And installing each LSP is a real chore with various competing plugins instead of the easy built-in coc install commands.
Apart from some node issues early on, CoC has worked well for me. At some point I’ll try the native lsp, but it seems like a lot of setup, just to get back to where I already am.
I'm using neovim with Coc (often does not work as I want it to) and ALE and friends, and it's getting sort of frustrating.
It's lots of fiddling with the vimrc, each year a new better extension that I can never make work, etc.
What I'd like is some editor that integrates LSP, treesitter, FZF and friends so I don't have to configure everything, while still having the modal+command model of vim.
Recently there was an editor that seemed to fit the bill (I think called Hex), but it seems those "keyboard oriented" editors are more usually "american keyboard oriented", in that the bindings don't make sense for non qwerty keyboards, and remapping everything is frustrating.
Essentially, I think I want an full-featured IDE with vim's extensibility and modal approach.
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.
Indeed, it seems to tick quite a lot of boxes.
I'm a bit confused on how to make it work with my old vimrc and plugins, and it doesn't seem to support julia's lsp yet, but I'll wait a few months, and hopefully this will be the solution I was looking for. Thanks!
VS code + the popular vim keybinding/mode extension for its editor.
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.
Neovim is great. I've moved from a very large custom vim setup to a slightly modified LunarVim [1] config (requires Neovim 0.5+), which takes full advantage of tree-sitter and LSP. Loving it so far.
I'm interested in what modifications you have made. I've been trying LunarVim a bit for the last week and am on the fence about going back to SpaceVim or just bare neovim. Not sure, still evaluating...
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.
Don't get me wrong I prefer lua to vimscript in almost every way. For migrating my existing settings, I didn't see the need to translate to lua, `vim.api.nvim_exec([[ ... ]])` and `vim.cmd('source ' .. path_to_vim_file)` work wonderfully. It's a joy to use lua for refactoring the remaining logic.
Integrated LSP is quite nice (and the ecosystem around it is just getting started), but it’s not the thing I’m most excited about.
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.
Tree-sitter based text-objects are one of my favourite parts of neovim 0.5 too. Now I can have class, function, parameter, and comment text-objects that can be manipulated as easily as words or paragraphs.
There's a few really cool things. The built in LSP is pretty clean compared to clunky nodejs or python plugins which I've found to clog down on huge codebases. The syntax engine has been improved by a tree-sitter algo, so it's way more robust with the syntax hilighting. And while I haven't messed with this yet you can do the whole config file in Lua now, which sounds pretty powerful.
The improved tree-sitter code parsing also allows for stuff like this which you won't find fully implementable in mainline Vim yet:
I've been using the nightly builds for a while now, and the language server support works very well, but for me the most exciting part of Neovim is Lua. Lua isn't the headlining feature of v0.5, but the API has still grown a lot since the last release.
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.
Originally the big selling points (IMO) were that it supported async plugins and an embedded terminal. Vim added both of those in version 8. For whatever reason this issue bugs me enough to keep me from switching https://github.com/neovim/neovim/issues/1496. I tend to open things like :!tig and neovim can't do it.
I did it a while back to see if I would notice anything different. I moved to vim a few years ago on a whim after using emacs for decades, so I am far from a vim power user, but with the modest configuration I use, I couldn't tell any difference, so I figured I would keep using it until I ran into a situation where neovim failed in some way that vim didn't. So far (maybe 6 months?) I haven't run into any issues, and I don't think I've added any plugins to my setup that would only work with neovim. This is all to say, it's probably a fairly easy experiment to switch with a fairly low risk of issues if you switch back.
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.
> you can bring over your vim config and it'll just work.
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.
Yeah, that's Neovim 0.5. But it's been like this for years: when I tried Neovim 0.2 (or something? I don't recall the exact version, years ago anyway) I also got many errors and incompatibilities.
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.
Compatibility was a goal at the start, but now it seems to be on a "best effort" basis at best. It's very much non-perfect because opening anything in neovim with my Vim config gives me a forest of errors and loads of things don't work, including some pretty basic stuff like expression mappings. See my other comment in this thread as well.
That's actually a negative for an existing user like me. Every time I upgraded to Neovim I ran into breakage with my configuration. Eventually I burned out and returned to Vim.
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.
It's true that "all patches go through Bram", but Vim has other maintainers as well and there's loads of people working on it. I had several patches merged with feedback from several non-Bram maintainers, with faster than average turnaround times I might add (i.e. several days or less before it ended up merged in Vim).
Well, a lot of people have come up with good reasons, but for me, it really comes down to the old repairman's adage: there are two kinds of people, those that piss in lifts, and those that do not.
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 really hope for one day to have Kakoune-like selection-first and multi-cursor functionality in Neovim. After moving to Kakoune i just can't go back to Vim, but Neovim's advancements make me jealous.
Congrats on 0.5, another release that looks great!
My heart is with vim but I switched to emacs as I love orgmode too much for note taking. I tried a few vim orgmode plugins but they seemed quite flakey even though I only really use orgmode for outlining. Excuse my ignorance but could all this LSP/Lua stuff allow neovim to take over from emacs?
I’d say cautiously maybe. Using lua to me seems like it could open doors for neovim that before we’re either not possible or very complicated to do with vimscript.
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?
Thanks for pointing out Fennel! every since I learned a little of elisp I really enjoyed the experience but common lisp seems like a beast to big to take on, clojure run on java and tbh I'm prejudiced against it... but fennel is just a simple lisp that runs on lua with no overhead? now that's something I can get behind!
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.
I've always scratched my head at this plugin. Is the idea that you have both a VS code configuration for all the stuff around the editor (themes, UI stuff, all kinds of fancy VS code features like its file tree, git tree, testing, etc.), and a neovim configuration for the editor component itself? How do language servers and such work--are all the slick one click VS code installed extensions ignored and you're back to twiddling and tweaking and googling neovim config to get LSP working?
I think you have it right: neovim for your fingers and VS Code for the larger programming environment with all its features. I don't know how LSP is integrated, but it seems to work.
BTW, I ran into too many corner cases where VSCodeVIM's emulation broke down.
I have been using this plugin for a while now and it is pretty solid. Most vscode plugins and vim plugins can work together nicely. For LSP you should just use the one built into vscode.
vscode-neovim really depends on nvim 0.5 I was using a neovim 0.5 nightly before this was released. It's not perfect but it's a LOT better than VSCodeVim.
One little-talked about advantage of Lua support is that you can now write your vim config/scripts in one of the various Lua transpilers like moonscript [0], or maybe even typescript [1]!
I have been waiting for 0.5 for ages. While most of us are trying to justify one text editor over the other, I am using combination of them depending upon the usecases. I use Neovim most of the time and use Vscode for special cases like getting previews on Markdown, PlantUML, and stuff.
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.
> It would be great to have a command that lists all the available commands in Neovim
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.
What is the value proposition for moving from vanilla vim to neovim? I see all the features on the neovim repo, but almost all of them seem aimed at developers rather than users. I've considered switching, but I'd have to move to a .nvimrc or something, update my install scripts and Ansible, etc., and I'm not sure what I'd gain from it other than "extensibility". If there are concrete benefits for normal usage, I'd be willing, but I'm not sure what those would be. Am I missing things?
I initially switched because it allowed me to simplify my configuration. This was even before Lua integration was a thing; it had better defaults, and the client/server architecture appealed to me. I also liked the idea of a re-factored, more-modular, possibly faster core application.
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.
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!
Lua is much nicer for scripting, yes, but support is not there yet. There are a couple missing APIs, and just some overall verbosity that is still being cleaned up and worked on last I checked.
I'd love to love neovim, but is seems there's not a easy way to install a "self contained subset". For some langs it misses some "OS" dependencies, resulting in sluggishness and annoying errors all over the place, when I just want to open a file from the terminal or in a non-IDE.
If someone knows a way to install a version of neovim that does not need OS deps...
Nice work! One small piece of feedback. Maybe I'm alone in this but I'd to see default keybinds and config for LSP. I like to keep my config small and defaultly and this:
You're not alone. I find it crazy that you're supposed to write a callback handler, and then register the handler inside a for loop over each server. This feels more like programming inside a framework, than writing a config file.
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.
If anyone is interested in migrating their config to lua, or doing some basic scripting, there's an excellent and pretty comprehensive guide here: https://github.com/nanotee/nvim-lua-guide
NeoVim is very tempting to me. I've been tweaking my Emacs config for 5 years, and I'm very happy with it, but only on my Ubuntu computers. On Windows, Emacs runs like garbage (slow, no double-buffering). I might have to switch to NeoVim, at least on Windows.
The Emacs experience on Windows could be faster, but having switched from Neovim to Emacs on macOS I do not want to go back to Neovim now (and I was running the Neovim 0.5/dev branch with LSP and treesitter integration for some time). Your time might be better spent on improving Emacs performance on Windows if you can. I haven’t used Emacs on Windows for a little while, but I wonder if running it via WSL2 with the new Linux GUI integration is better than the native Windows experience?
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. :-)
But neovim is only getting started. In a few years, the benefits of elisp over lua will probably be nil, and luajit is faster. I expect a lot of these points you make (which are valid) to become less and less relevant. First examples are already there : treesitter is as clean as can be, and telescope looks extremely nice. I'm waiting to see what people come up with for git, now that they don't have to learn vimscript or use slow python plugins.
That sounds a lot like the old annual joke about Bluetooth: “sure, we know it’s kind of rough around the edges today, but you just wait – it will be amazing next year!”
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.
You don't know enough developers or engineers. Much like; "If you find that you are always the smartest person in the room, you are in the wrong room."
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.
Don't worry there's lots of us mediocre humans using it too.
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.
> The best developers and engineers I’ve known all used Neovim. Coincidence?
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.
Bundling in a bunch of plugins[1] feels semi-cheating for shipping a new release, but I'm ok with it. I do get a bit of a monolithization vibe, and it kind of scares me to think that neovim might get stuck with some ever-ossifying codebases it shouldn't have pulled in, but overall I think the gains of building a more rich, integrated, baseline editing environment probably justifies the damage of consolidation/picking one.
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.
This isn't that big of a deal. vim is installed by default on all mainstream unix systems if not installable on any system of your choice. Neovim should be a more comprehensive vim.
> Bundling in a bunch of plugins[1] feels semi-cheating for shipping a new release
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.
