5 ms·

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 com

by spdy 10y ago

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

romgrk 10y ago
This is what is now possible with Neovim: https://www.youtube.com/watch?v=TI5azVeDUDo https://www.youtube.com/watch?v=TI5azVeDUDo
shazow 10y ago
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/discussion 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/wXmJuL4PDQAJ 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/XZEXxaxDDQAJ 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.
- mempko 10y ago
  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.
  - fatbird 10y ago
    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.
    - mempko 10y ago
      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?
      - fatbird 10y ago
        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.
        mempko 10y ago

by spdy 10y ago

romgrk 10y ago

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

shazow 10y ago

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/discussion 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/wXmJuL4PDQAJ 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/XZEXxaxDDQAJ 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.

mempko 10y ago
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.
- fatbird 10y ago
  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.
  - mempko 10y ago
    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?
    - fatbird 10y ago
      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.
      - mempko 10y ago