The main devs of NeoVim offered to work out an api for both versions but it never happend.

Seems like we are now in a feature war between both lets see who comes out winning. This whole thing could have happend so much smoother for the community but stubbornness sometimes lead to interesting innovations :).

If anyone is curious, here is the thread in question where the vim async API was proposed and the neovim devs proposed collaboration and were shut down without actually looking at the details:

https://groups.google.com/forum/#!topic/vim_dev/_SbMTGshzVc/...

Some choice posts:

- Bram (vim author's) response to whether he looked at existing implementation in neovim: https://groups.google.com/d/msg/vim_dev/_SbMTGshzVc/wXmJuL4P...

- Thiago (neovim author's) response to Bram, which was ignored: https://groups.google.com/d/msg/vim_dev/_SbMTGshzVc/XZEXxaxD...

There are lots of other instances of this exact interaction between neovim and vim over and over, it's infuriating. Neovim was started precisely for this reason, an async proposal was made (in 2014!!) which was rudely shut down and all efforts of collaboration were ignored.

I'm sorry, but Thiago's response is clearly patronising. Giving Bram advice on how to "properly" implement channels and job control. Suggesting taking the old infamous old patch.

I got pissed off for Bram reading it.

Also Bram had much more detailed and valid criticism about neovim's implementation above the response you linked. Did you intentionally link that one to make Bram look bad or did you simply not read the whole thread? I'm betting on the former.

Thiago's response comes from several years of experience actually doing and having done what Bram what proposing: first creating the async path for vim, fighting for its acceptance, then forking vim, implementing it, and shepherding it as the key feature of neovim. So far, I've heard no major complaints about neovim's async; it's actually been the killer feature so far.

Bram might be the more experienced programmer overall, but for implementing async in vim, I'll take Thiago's learned opinion over Bram's 'the horse has been dragged to water' solution anyday.

I wasn't talking about Thiago's credentials. I was talking about the tone in his reply which was clearly abrasive.

Brams criticism is valid about Thiago solution. Forcing msgpack is less than ideal. It's clear Thiago is learning as he goes along. Taking his work without reflection would be silly.

Also it is also clear neovim wants plugin writers. So they want vim to be compatible with what they made so they can grab users.

Why should vim care about being compatible with neovim?

I don't agree with your reading of Thiago's tone--you found it patronising, I found it trying hard to be polite to Bram, who's being the same dismissive senior dev he was when he rejected Thiago's first and second attempts at patches to do what was done very well in neovim.

As for why vim should care? Because at this point I'd put money on neovim as the long term winner, and if I were Bram, I'd worry about vim joining vi on the sidelines as 'still developed, still in use, but not the vi everyone uses when they log into a linux box'. I'd look at my codebase and neovim's, at my toolchain and neovim's, at my community and neovim's, at my velocity and neovim's, and I'd imagine neovim eclipsing vim over time.

Maybe that's fine. But Bram is hardly some god-king who's position as foremost developer in the vi universe is a lifetime appointment--especially after he took that position from Bill Joy.

Why are you on the side of someone who has a hard time being polite. I read the original threads about Thiagos original patch and he was in the wrong. He ignored issues that were outlined and it was clear the patch was not ready. He was not polite.

Once again Bram brings up a valid issue with neovims design about using msgpack for RPC. It just adds another layer of difficulty.

So explain to me why vim should include such an obviously flawed design?

By "trying hard to be polite", I mean he was making an effort to be polite when he had no need to be after Bram was already rude and dismissive, not that Thiago has trouble being polite. Read the neovim issues in github: Thiago is a model of good-natured engagement with almost everyone. In the original patch request thread he's far from impolite, and he's more polite than Bram is.

And "makes debugging difficult" is an observation, not a criticism or valid reason to reject--it's certainly not detailed, as you said. Yes, it's more difficult debugging it directly, but the architectural separation makes the components more loosely coupled and more easily tested in isolation--it's a valid tradeoff, and one the neovim has demonstrated to work well in actual fact.

I mean, it's an accomplishment for Bram to add async to vim, but let's not forget who actually did it first, successfully, and along the way accomplished a lot more.

Why are you so hostile to neovim? By any measure they've done a tremendous job modernizing the codebase for vim and rejuvenating development of both neovim and vim.

Step back and ask yourself: if you were approaching both projects fresh, and asking which you might want to participate in, which would you choose and why, ignoring politeness on either side?

This is what is now possible with Neovim: https://www.youtube.com/watch?v=TI5azVeDUDo

Neovim already fragmented the community. Bram seems to have stepped up to the challenge bigtime since neovim announcement, as judged by his github activity graph.

https://github.com/vim/vim/graphs/contributors

This is misleading. Bram takes commit ownership of external contributors. Compare it to Neovim, which feels much more like a community: https://github.com/neovim/neovim/graphs/contributors

Also see the changelog messages in vim, and compare them to the changelog messages in neovim.

that was true pre-neovim too so we still can say that activity has increased signficantly post-neovim announcement.

I wouldn't say he's stepped up. It's all a reactionary response to Neovim. I dont think we'd ever have async in vim if it weren't for the neovim project.

That being said I hope they pull an io.js and merge taking the best of both vim and neovim, whatever that may be.

"Stepped up to challenge" is a reactionary response.

Something challenges you, your reaction is to ignore/quit or step up and respond.

you know what? I'm prepared to cut Bram Moolenaar a lot of slack given the goodness he gave us for 20 years through 7 versions of one of my top 3 pieces of useful software.

he's a great guy but at some point it's time to move on

Downvotes for speaking the truth and adding to the discussion. Thanks guys.

but move on from what exactly? Vim 8? Looks good to me....

Maybe you want to move on just for the sake of moving on? To a new generation? Can you explain why? Seems to me that the person who knows the code base 200%, who wrote/vetted the entire codebase, is better placed to add features, than newbie refactorers who didn't?

Those newbie refactorers took a 300k line codebase, removed 130k lines of cruft, got it working on a modern toolchain, created an actual OSS dev community without a bus factor of 1, and added two major new features (async and embedded terminal) of which vim has only gotten around to adding 1, while improving performance and laying the groundwork for another major new feature (embeddable) that vim will take years to catch up to.

And all of that while maintaining such good backwards compatibility that almost all vim plugins work unmodified. Plugin authors only need to lift a finger to take advantage of new capabilities like async.

I didn't switch just for the sake of moving on. I switched because by any appreciable aspect, neovim and the developers behind it are simply better than vim.

Thank you for elaborating on my point. Very well said.

While this may sometimes be true, it would be dishonest to claim that only the original author of a project should be allowed to maintain it. It's also incorrect, since distributions all maintain forks of vim as well. Given how much time and effort the NeoVim community has put into improving the state of vim (that includes refactoring, as well as much more significant features you ignored like async which NeoVim had first since the maintainer of Vim didn't want async), it is quite disrespectful to call them "newbie refactorers". Everything I've seen of the vim development community makes me feel that it is quite toxic, so I'm very happy with the more open development model that NeoVim has.

neovim will most likely merge good features from vim 8, but I find unlikely that the opposite happens. To be fair, I'm actually okay with that. One of the reasons neovim is where it is right now is because they forked it and because they keep it forked. I'm not sure how fast it would improve if neovim merged back.

can't imagine that happening unless vim drops some platforms it supports.

Well, at this point in time Amiga and MS DOS should probably go.

They're served decently enough by older versions and I doubt that any machine running those has the resources for features provided by newer Vim versions. Even if they do, the OS support for these features might not be good enough.

He did drop some platforms, although nowhere near as many as NeoVim did:

Omitted in this version are:

The 16-bit DOS, OS/2 and Amiga versions, these are obsolete.

The 32-bit console version for MS-DOS/Windows 95/98

The 16 bit MS-Windows version

async VIM - We had it 4 years ago with VIM-Dispatch.

https://github.com/tpope/vim-dispatch

If you know how vim-dispatch works, you'll know that it just opens up a split in Tmux/Screen or makes a new tab/window in your terminal emulator to run the command "asynchronously." While it does work, it's definitely a hack and not a feature of Vim.

Correction: Tim Pope managed to hack in a mostly-functional version 4 years ago.

Correction I linked Tim Pope's github page.

That never worked on windows.

You right about that I forgot.

Right. Frankly that's a disappointing response. One source software shouldn't be a competition. I'm still holding out for some kind of grand unification in the future. I'm sure this is becoming a nightmare for plug-in maintainers, because it's certainly a pain in the ass for users like me.