5 ms·

Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to impro

Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to improve a project they love, and finding no good options on howto do so. As for "getting behind it if it succeeds" lets hope not! I was a financial supporter of Neovim. I also have run the #vim channel on FreeNode for over a decade. They serve different goals. Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome. Vim is -- the default on many systems, shipped with fully working vi compatible mode, has literally millions and millions of users. It can not -- by its nature -- move fast and break shit. Vim has a much, older, slower development process -- from the days well before Github and friends... it might slowly open up -- but not much, because again, millions depend on it. This is also, awesome. I hope the very best ideas, once they are tested, debugged, and tested again will make their way up from Neovim to Vim, but it will be a very slow process. Neovim gives no thought to Vim -- because it can't -- it has to be its own thing to move forward. Vim gives no thought to Neovim yet -- it is an established, dependable, amazing tool... and Neovim has not yet risen to the point to even be worthy of a response.

exDM69 12y ago
> Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome. The first thing done to Neovim was to re-format all the code and then do some refactoring that breaks things. You can't make an omelette without breaking eggs but this practically burned the bridges behind and any hope of merging stuff upstream/downstream from neovim to vim or vice versa is gone. At least without significant manual labor. If you ask me, this was a premature move and the neovim guys should have tried to make non-breaking changes first with an opportunity for upstream-downstream merges.
- MetaCosm 12y ago
  The Neovim development path -- by design -- had no chance of upstream-downstream merges. It is a departure, not a premature mistake, but a decision. The code had to be re-factored to let the community in -- the Vim code is a horrific legacy cruft-fest that terrifies even the most brave developers. But it is a historical working one, which is hard to argue with -- look at those styling commits, they are wonderfully sane.
- lubomir 12y ago
  I do not know how much manual labor it is, but there are some pull request with merge of vim patches, so it definitely is possible (or at least someone thinks it is worth their time). E.g. https://github.com/neovim/neovim/pull/653 https://github.com/neovim/neovim/pull/653
dasil003 12y ago
I don't want a product that moves fast and breaks things, but I also don't want to carry the baggage of legacy support for strict vi-mode and whatever else ungodly edge cases vim continues to support. What I'd rather see is vim with deprecations and upgrades on a reasonably timed roadmap. It's obviously a lot more work to maintain a 7.x branch, 8.x branch etc, but this is much more sustainable and meets everyone's needs better than saying "fuck it I just want Sublime with better vim bindings". An editor is not something where I want to chase the flavor of the month and deal with constant plugin breakages, but neither is it something where I want to be stuck in the 90s forever. There has to be a middle ground. For the time being Bram's approach has earned my trust, and Neovim has to demonstrate many years of good project management and momentum before I will really be willing to trust it.
- MetaCosm 12y ago
  Those ungodly edge cases are what makes vim usable everywhere, and the default of the defaults on so many systems. That trusty vi command that works a certain way has been dependable since the late 1970s. But, that misses the point of Neovim a bit -- Neovim is about letting the community in (with all the good, and bad that comes with that). I suspect most people won't shift over to Neovim until either (1) They want to actually contribute something and find Vim proper far too daunting, or (2) because of the entirely new plugin model, some amazing plugin is only available on Neovim and it drags them over from Vim. The Neovim plan seems to be "in months to gain momentum, in years to gain trust" -- which is really the only way you can do it.
  - timc3 12y ago
    I am moving over to VIM because I disagree with some of the design decisions - for instance, I don't believe in a single gatekeeper to a application that I depend upon.

exDM69 12y ago

> Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome. The first thing done to Neovim was to re-format all the code and then do some refactoring that breaks things. You can't make an omelette without breaking eggs but this practically burned the bridges behind and any hope of merging stuff upstream/downstream from neovim to vim or vice versa is gone. At least without significant manual labor. If you ask me, this was a premature move and the neovim guys should have tried to make non-breaking changes first with an opportunity for upstream-downstream merges.

MetaCosm 12y ago
The Neovim development path -- by design -- had no chance of upstream-downstream merges. It is a departure, not a premature mistake, but a decision. The code had to be re-factored to let the community in -- the Vim code is a horrific legacy cruft-fest that terrifies even the most brave developers. But it is a historical working one, which is hard to argue with -- look at those styling commits, they are wonderfully sane.
lubomir 12y ago
I do not know how much manual labor it is, but there are some pull request with merge of vim patches, so it definitely is possible (or at least someone thinks it is worth their time). E.g. https://github.com/neovim/neovim/pull/653 https://github.com/neovim/neovim/pull/653

dasil003 12y ago

I don't want a product that moves fast and breaks things, but I also don't want to carry the baggage of legacy support for strict vi-mode and whatever else ungodly edge cases vim continues to support. What I'd rather see is vim with deprecations and upgrades on a reasonably timed roadmap. It's obviously a lot more work to maintain a 7.x branch, 8.x branch etc, but this is much more sustainable and meets everyone's needs better than saying "fuck it I just want Sublime with better vim bindings". An editor is not something where I want to chase the flavor of the month and deal with constant plugin breakages, but neither is it something where I want to be stuck in the 90s forever. There has to be a middle ground. For the time being Bram's approach has earned my trust, and Neovim has to demonstrate many years of good project management and momentum before I will really be willing to trust it.

MetaCosm 12y ago
Those ungodly edge cases are what makes vim usable everywhere, and the default of the defaults on so many systems. That trusty vi command that works a certain way has been dependable since the late 1970s. But, that misses the point of Neovim a bit -- Neovim is about letting the community in (with all the good, and bad that comes with that). I suspect most people won't shift over to Neovim until either (1) They want to actually contribute something and find Vim proper far too daunting, or (2) because of the entirely new plugin model, some amazing plugin is only available on Neovim and it drags them over from Vim. The Neovim plan seems to be "in months to gain momentum, in years to gain trust" -- which is really the only way you can do it.
- timc3 12y ago
  I am moving over to VIM because I disagree with some of the design decisions - for instance, I don't believe in a single gatekeeper to a application that I depend upon.