I've been using nvim exclusively for four months now. Perfectly stable (I think even more so than my vim was, I use lots of crashy plugins) and a perfect drop in, basically nothing changed for me when I renamed nvim to vim on my systems.
I wonder what their roadmap is for a 1.0 release. Is it a specific feature set, or stability in their MessagePack APIs? Is it years off, or just pending some big bugs/refactorings?
That's pretty impressive considering the amount of change they made. Keeping it small, compatible and adding modern features and design .. I'm tempted to read their repository just to learn about project management.
Damn it, I was wondering why my newly upgraded copy of Neovim suddenly stopped reading my .nvimrc (which is a symlink to .vimrc) Now I can fix it. Thanks.
I went through this on Friday after a spontaneous update of neovim. The help docs are well maintained, see `:help nvim`, or read online here https://neovim.io/doc/user/nvim.html
When I think about switching to Neovim, I feel disloyal and ungrateful to Bram Moolenaar. He has done so much for so many, and if Neovim takes off he won't walk away with much of a reward. How much code has been written in Vim - and almost every line for free.
That seems like a strange way to view things. What is he getting out of it now that he won't be getting out of it if neovim would take off? The only thing he has asked is that people donates to a few charities of his choice. Neovim has kept those recommendations front and center, and if it does take off it might end up extending the user base causing even more people to donate. That's not a bad legacy, is it?
It's open source. That's what's supposed to happen. Vim is great but the developer is by all accounts the bottleneck in any progress towards cleaning up the code, adding async support, letting people make susbstantial changes to how the project works so it's essentially stagnating. Neovim should give it a huge shot in the arm and make it possble/easier for more people to write better plugins. There's no downside to it; if you're happy sticking with vim that's totally awesome too, but I can't help but see too many new plugins being started for vim once this is out (well, v1.0 on all platforms; perhaps a bit too soon now) because..well, what would be the point?
I have been using neovim for months now with no issues I can attribute to neovim. The terminal mode can be useful, although I still prefer my current tmux setup. I have been using it with linux and osx, building from source.
I suspect most users could download neovim, symlink their .vimrc/.nvimrc, alias vim=nvim and not be able to tell the difference.
As a note, one does not symlink to `~/.nvimrc` anymore. Things are now in `~/.config/nvim/` with the rcfile in the `~/.config/nvim/init.vim`. This was a bit of a surprise for me the other day when my `nvim` instance failed to pick up my settings and refused to identify a `backupdir`.
If that's the case why use it? I'm still holding out for Neovim's killer feature; I'm not switching just because they use more modern APIs or removed Amiga support; I don't care about those things as an end user.
Proper async plugins are the killer feature. For example, if you're using neovim then Syntastic doesn't block the UI when it runs checks. Also off the top of my head, built in terminal emulator and 24 bit color support and far easier integration with external programs. Eventually my hope is that we will have real vi-mode plugins for IDEs that actually load up (neo)vim, though those sort of things are still in their infancy.
I'm a very heavy vim user and have been using neovim for a while now. It causes me zero issues even following git master, but I can definitely notice improvements.
I hope there's more that than. I personally don't use any plugins for which this is a problem. Not doubting those plugins exist, but apparently you can get by as a Vim user without them.
I see potential for the embedding api. If I could run Vim on a server and connect to it from a web app I would find that to be very compelling. Maybe there are other features that will set it over the top, but I'm still waiting.
If you're using vanilla vim I don't think there's a whole lot neovim will offer you at present. I think there will eventually be some performance improvements in the core areas, but they haven't really started on that yet.
Async support is a big deal for a lot of people though (and it's neovims original raison d'etre). For example, not having :make (well, :Neomake) block on compile is pretty significant by itself. Under the hood getting real async tasks required/requires a ton of rewriting because of how Vim was architected. Those changes were made deliberately and weren't just so that they could use all these fancy new libraries.
So I guess I'd liken it to Windows when it went from the 98 days to WinNT/2000 - keeping things working about the same while laying the foundation for bigger improvements later.
On the other hand, I don't see much downside to moving to neovim either. It is interchangeable (in my experience) with vanilla.
> If you're using vanilla vim I don't think there's a whole lot neovim will offer you at present.
My vimrc is 80 lines, I don't feel it's vanilla at all, but I don't use :make or probably any other commands that launch subtasks so I guess this is what sets me apart.
I meant more with the plugins, but in any case regular vim isn't going anywhere either. I think there's eventually supposed to be hooks for building better GUIs and external integration, which will probably be the turning point when a lot more people switch over.
For me asynchronous plugins are a killer feature, which renders classic vim unusable for me.
I run linter every time I save, which made vim's UI lock for noticeable time on non trivially small files. With neovim linting is smooth as butter from UI/UX perspective. Also there is asynchronous make, and other possible features/plugins.
I've been using NeoVim for a while now and have been all in all pretty impressed.
One thing I haven't been able to get to work though has been asynchronous plugins. It'd be great if I could get syntastic running in the background. Are there any good articles to read about getting this up and running?
The idea is that the plugins themselves implement asynchronous functionality. Neomake is a new plugin that checks syntax just like syntastic, but does so asynchronously. Another popular async plugin is vim-plug.
I've been using neovim for over 6 months and can't go back to vim, mainly due to asynchronous linter.
In the last week neovim changed their config file location from `~/.nvimrc` to `~/.config/nvim/init.vim`, though config file AFAIK is fully backwards compatible to vim, as I use the same vimrc for neovim and vim.
Just switched and it might be a placebo effect, but everything from scrolling to switching files seems a bit...snappier. Is this due to the async improvements? Do plugins have to opt-in to be async or does the core re-implement previously synchronous functionality to be asynchronous?
There have been drastic changes to the event loop and redraw logic, which makes some operations feel "different" (some slower, some faster). We have not intentionally made any general performance improvements, because the performance bottlenecks of Vim/Neovim hinge on the regex engine (which is primarily maintained by Bram) and vimscript interpretation--nothing else.
Job control is implemented in Neovim for co-process (not in-process) coordination. This means that potentially long-running vimscript calculations can be offloaded to a child nvim process. But Neovim 0.1 does not have a faster vimscript engine per se.
I didn't really considered Neovim until recently, as a serious vim user, I didn't really feel I want anything but original.
I started using it because plugin for pairing was only working on it. I can say I was completely surprised and impressed with performance. I still use Vim, but I have Neovim handy and I could probably replace it and not even notice difference. Very impressive effort.
So does anyone know what kind of magic happened in August? They're scanning the code using coverity and the graphs don't seem to make sense: (https://scan.coverity.com/projects/2227)
Probably. Just based on the graph, I'd guess that in June someone started a push to get them to zero outstanding issues in Coverity, starting with the ones that were clearly bugs, and then in August they were down to just the ones that they thought were false positives.
Neovim articles seem to be accompanied by a bunch of top-level comments saying how unreservedly wonderful it is and offering nothing constructive. It looks like shills (but I of course don't know the intent of any particular commenter).
Well, the first comment I see is someone worried about the open source vim project being used in an open source manner and the original vim author losing money or something, in addition to people saying they're happy about the new asnync plugins and properly managed, open to everyone development model, so there's really something for everyone here!
I did a `ls -s .vimrc .nvimrc` along with very few changes (like replacing Command-T with Command-P). Everything ran just fine. I still don't use nvim daily, mainly due to my old habits. Perhaps I should alias nvim as vim.
Current status seems to be working on packaging of dependencies first, since some of neovim's dependencies are either missing or out of date in Debian. A few of them have since been done (unibilium and libtermkey are now in Debian, libuv is updated), but a few are still in progress.
Great news, long overdue. Neovim has been quite stable for many months now. Most people I know use the nightly builds, which was fine until they introduced some BC breaking stuff this week, which threw everyone off.
Bunch of snobs on gitter criticizing users for installing nightlies and expecting stability... But that's what happens when you don't tag a release after almost two years of development
I've been using `nvim` on OS X and Arch Linux for the last few months. I am very pleased with it. Excellent stuff, and the newsletters were a great way of keeping the indiegogo backers informed.