8 ms·
Has Bram Moolenaar ever publicly acknowledged the influence of Neovim on Vim 8? At the very least, Neovim provided the market research to show that async was wo
by akkartik 10y ago
Has Bram Moolenaar ever publicly acknowledged the influence of Neovim on Vim 8? At the very least, Neovim provided the market research to show that async was worth doing.
- deadbunny 10y agoI've not seen anything which is disappointing, the NeoVim team have done a fantastic job at modernising Vim. I've not followed Vim development very closely but the whole async thing did give me a chuckle when I read about it after years of not accepting async patches. A real shame he made it incompatible with the NeoVim async with no real reason.
- tsul 10y agoHe mentions it here: https://www.youtube.com/watch?v=ayc_qpB-93o https://www.youtube.com/watch?v=ayc_qpB-93o
- owaislone 10y agoNeovim is Vim for me and many other users. Vim is irrelevant to me now. The community is rallying behind Neovim and it shows great potential. It just needs to be bundled by major distros so it can be installed on servers with 1 command and that'll be the end of old Vim. Bram has done a tremendous job with Vim but it's time to move on to the Vim of the future.
- vbezhenar 10y agoWhy would it be the end of old vim? I've never used neovim and I don't plan to use it, vim is perfectly fine for me, as it is. I guess, most of vim users don't even know of neovim. Sure, it's good to have a choice.
- hxegon 10y agoA lot of other comments make related points that kind of dance around this, but here it is: The major improvements of neovim aren't (directly) user facing. It's a major refactor, which makes it immensely easier to maintain and contribute too. Neovim isn't a vim reinvention, it's a vim renewal.
- kedean 10y agoWhat I think is interesting here is that Neovim is entirely contrary to the original point of Vim, as presented in the article: a vi available on non-Unix systems. It was portable, so it could be run anywhere. Now Neovim's selling point is that it DOESN'T have all the code that enabled that portability. Not suggesting one way is better or worse, but I think it's interesting.
- elsjaako 10y agoFor me the major improvement is that it puts the settings in the .config folder. I like this because I keep my settings in a git repo. The main advantage on the other hand is that my friend stopped bothering me about having to switch to neovim, which I guess is a non-issue for most. Now he's trying to get me on to zsh.
- deong 10y agoI've kept pretty much all my settings in a git repository for years -- you don't need the program to explicitly make that easier. $ git clone <<repository_url>> $HOME/config $ ln -sf $HOME/config/vim/vimrc $HOME/.vimrc
- sigzero 10y ago
- manaskarekar 10y agoYes, http://www.binpress.com/blog/2014/11/19/vim-creator-bram-moolenaar-interview/ http://www.binpress.com/blog/2014/11/19/vim-creator-bram-moo....
- falcolas 10y agoI think that so long as the primary rhetoric from the NeoVim camp is "vim is dead, long live NeoVim", with a dash of disrespect for Bram and his goals of continued platform compatibility and coding style... I personally don't expect such acknowledgement. Doing so might make Bram the 'better person', but I wouldn't blame him if it makes him a bit resentful.
- hxegon 10y agoWhat? I've seen tarruda and co. explicitly express gratitude and thanks to Bram.
- falcolas 10y agoBy critiquing his reluctance to accept patches because he'll be stuck maintaining that code? By forking Vim and removing some compatibility and legacy support features when tarruda's multithreading patch was not accepted? No, the core contributors have not been outright in their criticisms, but IMO the fork itself shows a lack of respect for Bran's work and a lack of willingness to work with him to make Vim better. And now tarruda has stepped back from NeoVim, perhaps recognizing himself the cost that Bram bears. By simply contributing to the tests - one of the outright critiques of Vim itself - they could have brought a lot more confidence to accepting such patches to Vim, but they chose to take their ball and play elsewhere instead. What frustrates me the most is that instead of two branches of Vim that are moderately better (with the future of one of the branches being left behind), we could have had one which was much better.
- linsomniac 10y agoExcept that the direction we were moving wasn't one branch that was much better, it feels like it was no improved branches at all. vim7 was a great improvement, and when I show people the time travel capabilities it blows their minds. But that was a long time ago. With the number of people to whom vim is very important, I'm surprised there isn't more results coming out of it. Though maybe it is mostly that the core doesn't need to change and innovation can happen in the plugins? That is certainly true to some extent, but the async stuff was way overdue.
- greenspot 10y agoGood point. A recent upvoted post From Reddit's Vim sub [1]: "I am super surprised that everybody talks about Vim 8 but almost nobody mentions that... - Bram Moolenaar did the last major version ten years ago - The recent years of Vim's development were almost stalling - Bram publicly questioned the Neovim team's efforts creating a fork and bringing new essential stuff like async to Vim—he even made kind of fun of them After Neovim came out and has been developed at fast pace, Bram surprisingly presents Vim 8 with the stuff we wanted which before he decided against—all the stuff Neovim did and of course incompatible to the fork. Bram's decision on being incompatible should be challenged and discussed, would love to hear his thoughts. Since no money is involved, his decision feels even more awkward, why not welcome competition or potential contributors, being a team player, work together or merge? Or is it Bram's injured pride, the fear of getting irrelevant with some piece of ancient software? Whatever 'meaningful reasons' Bram chose not to support a fork, now we are left with incompatible Vim variants which damage the entire Vim ecosystem. I guess that most distributions will package Vim 8 with their distributions, just because not everybody has followed all the happenings, and Vim 8 sounds like a solid choice, like going with the mainstream. So, Vim 8 might get the next standard and an awesome fork could die which I find sad. The Neovim team has been disrupting, they went ahead and it's a community developed software which is a huge differentiator to Bram's work and codebase of controversial quality. What are your thoughts? Should we support both versions and should we write plugins for both or focus on one? Or is competition good and the Neovim team will deliver more and prove that still a community developed Neovim will outperform Vim in the long run? Don't get me wrong, this isn't a rant, Bram created with Vim an fantastic piece of software—this is about the question how we should keep competition which helps the entire ecosystem so we don't end up with a dying fork and original Vim's development slowing down again for the next ten years. One idea is that all distributions should either still package old Vim 7.x only to let people decide themselves or always package both Vim 8 and Neovim together. But how should we get there?" [1] https://www.reddit.com/r/vim/comments/52q4ul/about_vim_8_and_how_to_keep_the_vim_ecosystem https://www.reddit.com/r/vim/comments/52q4ul/about_vim_8_and...