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 :).
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 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.
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.
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?
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.
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?
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?