For better or worse they awoke the sleeping giant[1]. Curious to see how things play out with the fork (i.e. will vim users stay put or move on to neovim in the coming months/years).

[1] https://github.com/vim/vim/graphs/contributors

It's unfortunate that vim introduced similar features for managing running processes, but in a completely incompatible way, such that one vim module can't easily support both.

I'm not sure how it could be 'for worse'? Even Neovim benefits from the uptick in Vim patches, because they actually merge many of them into Neovim. So it seems like it can only be a good thing. Better editors for everyone.

That's one way it could play out, but that's not the way it did play out. Vim ate Neovim's lunch because they took so long to create a release that Vim was able to copy their best features. Worse yet, they did this in a way that is not compatible with Neovim. There is a chasm between Vim and Neovim that is growing, and the incentive to cross it is shrinking.

As someone who has watched closely Neovim's development since its announcement, and used it as my daily text editor for literal years, I feel sad to say that it is early-stage vapourware. They kicked vim into action, then vim kicked them out of it.

Hm, ok, that's interesting. I guess I stopped following Vim's progress once I switched to Neovim. It still seems to me that Neovim has the right overall approach (through cleanup, shedding ancient compatibility layers), but if that doesn't yield an increase in velocity in the short term then I guess it wouldn't be a big advantage.

Vaporware?! That's atrociously uncharitable. Care to defend that characterization? Did you call Gmail vaporware until they took the 'Beta' label out?

Vim didn't eat Neovim's lunch. It made its own lunch. Vim8's async feature is a copy only in name. Comparing both async APIs, I'm almost certain that Vim8's was added spitefully. It's just so obtuse compared to Neovim's.

Well, that one is the one people are using. Now that the question among plugin developers is "Vim or Neovim?" which one do you think they will choose? It's totally possible that Neovim will need to adopt Vim's inferior API for compatibility reasons, like they're doing with the VimL<->Lua compatibility layer.

The same question can be asked about Vim 7.4 and Vim 8.0. Which should a plugin developer choose to support? I'm a plugin developer and choose to support any version that has the right features for what I'm accomplishing. For most things, there isn't anything special that needs to be done.

Slow, incremental, consistent, disciplined hard work leads to amazing results.

Congratulations and huge thanks to the maintainers, I use neovim every day and love it.

I read that article and didn't get a good handle on any features that would motivate a transition from Vim. Any links you could provide?

For me, I like:

- Neomake ( https://github.com/neomake/neomake ) which I use for async linting. I know this is now working in Vim 8, but I've been using Neovim for a while and this was exclusive for a while.

- Vim-test ( https://github.com/janko-m/vim-test ) uses `:term` for running your tests from within vim -- this is most useful because I have a shortcut to test from current editing file, etc. I know this is also possible in vim now.

- Mapping Meta keys in terminal -- opens up a bunch more shortcuts that weren't available before

- `inccommand` This I believe is only in neovim, and likely not enough for anyone to switch for

Cons: - Not in distros, gotta install manually via their PPA

Thanks for the link to Neomake - Neovim is still a first class citizen for it, and it was a pain to get it working on Vim (and several bugs for Vim have been filed, debugged and fixed in this process).

Thanks for making Neomake!

Regarding distros: Arch has it.. ;)

:term to run a terminal in a vim window.

Also, much more sensible defaults.

An embedded terminal emulator is exactly what Neovim should not have.

Care to elaborate?

Neovim's goal is remove cruft and shrink the codebase. Adding a terminal emulator, a completely orthogonal feature that makes no sense in a text editor to begin with, is contrary to this goal. They wasted time and worked on the wrong thing.

Vim already allows you to use :shell. Neovim took it a step further with the added benefit that you can treat the output as buffer text. Just because you can't see the advantages this gives developers doesn't mean it was a waste of time.

:shell is completely different. That's vim stepping out of the way while you run a subprocess. Moreover, vim having it is not an argument for Neovim to have it. If vim really had a terminal emulator Neovim should have removed it.

Cool, but why?

Avoiding multiple levels of window management, when you want to edit multiple files and have one or more additional terminals available.

For instance, I've used this to edit a manpage with a live preview to the side in another window. Doing the same thing with screen would require running vim inside screen, and doing window management with both screen (for terminals) and vim (for everything else).

I like being able to have a vim window that has a terminal in it, there are some cases where I just prefer to have it in my terminal environment rather than switching to another real window. Mostly this is for things where I want to be in the same directory as my editor to run greps through my source, etc...

It's also nice sometimes to do something and then be able to search through the history with "/". At times I've then gone back and cut and pasted between the terminal output and a document I was working on, rather than using my window manager cut and paste.

I was, however, fairly surprised that I could no longer ":sh" out to run something. Had to get used to ":term" or ":spl term://bash".

> I was, however, fairly surprised that I could no longer ":sh" out to run something

Honestly, :sh always felt weird in vim.

Either you are in a terminal, and Ctrl-Z is a much better experience, since you maintain your existing session.

Or you are in the GUI, and the terminal emulation is poor and slow.

Speaking practically, if you're using a terminal to use Neovim, you get consistent window management. If you're using one of Neovim's GUI clients, you also get a terminal in the GUI's frame.

no more confusing C-w and C-b in tmux, perhaps?

Same here. Scrolled through it and the only thing I got is that there is a command called ":smile" which is not worth switching to me.

Doesn't mean there is none, it's just hard to find.

:smile is a vim command that was introduced in the new version of vim, I'm not sure but it seems like they are making fun of it. There's always been a bit of hostility between the neovim people and Braam, last being the fact that Braam finally implemented jobs in Vim 8, but using a different API than neovim.

It's a joy to read such a polite newsletter. Friendly towards to original source. Friendly and open as a community. Everythings seems well organized and distributed. Well done!

Also thanks a lot for the tool, I use neovim almost daily.

As a daily neovim user, love the progress! Here's to a great 2017!

Fantastic work by the Neovim folks as usual. However, this sentence stuck out to me

> The API should only grow, not break

This seems to ensure eventual bloat.

Is neovim packaged for distros?

Arch has it: https://www.archlinux.org/packages/?name=neovim The -git version in AUR: https://aur.archlinux.org/packages/neovim-git/.

I've been using Debian's neovim package for the last several months, but I use the unstable repositories. I think it'll be officially packaged in the next Debian release though.