3 ms·

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made

Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds? The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell of a lot.

bpierre 13y ago
Quoting his answer [1] in the vim_dev mailing list: It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly? Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users. [1] https://groups.google.com/d/msg/vim_dev/x0BF9Y0Uby8/94tmiaBvFOgJ https://groups.google.com/d/msg/vim_dev/x0BF9Y0Uby8/94tmiaBv...
- mikaelj 13y ago
  The refactorings thus far have been specifically aimed at making Neovim work better for /developers/. Which in turn will make it better for the users. A very good way of thinking.
CyberMuz 13y ago
He is not very enthusiastic about it. Here is his comment about Neovim from two months ago. I don't know if he changed his mind in the meantime. https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...
aidos 13y ago
I've only seen his original post on it [0] - not sure if anything had changed since then. For selfish reasons I'm behind neovim but I can see that it puts Bram in a bad position, which is unfortunate. He's done so much work for all of us (vim users), and ultimately this project just adds to the work he has to do (and makes it even more thankless). He'll be dealing with incompatibility issues between plugins trying to support both systems. Ultimately, I guess he'll have to make a choice as to which codebase to support, by choosing neovim he's deserting everyone on esoteric systems. I think that may be the best outcome; Neovim becomes the new standard, Bram switches over and leaves vim to die. But then what control does he have? It's one of those situations, it seems like a good idea, and could be a massive net win. Then again, it could also really destroy the project. [0] https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...
MetaCosm 13y ago
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 13y 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 13y 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.
deleted 13y ago
[deleted]

bpierre 13y ago

Quoting his answer [1] in the vim_dev mailing list: It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly? Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users. [1] https://groups.google.com/d/msg/vim_dev/x0BF9Y0Uby8/94tmiaBvFOgJ https://groups.google.com/d/msg/vim_dev/x0BF9Y0Uby8/94tmiaBv...

mikaelj 13y ago
The refactorings thus far have been specifically aimed at making Neovim work better for /developers/. Which in turn will make it better for the users. A very good way of thinking.

CyberMuz 13y ago

He is not very enthusiastic about it. Here is his comment about Neovim from two months ago. I don't know if he changed his mind in the meantime. https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

aidos 13y ago

I've only seen his original post on it [0] - not sure if anything had changed since then. For selfish reasons I'm behind neovim but I can see that it puts Bram in a bad position, which is unfortunate. He's done so much work for all of us (vim users), and ultimately this project just adds to the work he has to do (and makes it even more thankless). He'll be dealing with incompatibility issues between plugins trying to support both systems. Ultimately, I guess he'll have to make a choice as to which codebase to support, by choosing neovim he's deserting everyone on esoteric systems. I think that may be the best outcome; Neovim becomes the new standard, Bram switches over and leaves vim to die. But then what control does he have? It's one of those situations, it seems like a good idea, and could be a massive net win. Then again, it could also really destroy the project. [0] https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8 https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...

MetaCosm 13y ago

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 13y 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 13y 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.

deleted 13y ago

[deleted]