Neovim team has always been positive towards Vim. This post doesn't paint the Vim team as being hostile either. However, I really wonder how practical a merge is, considering that neovim isn't a fork or Vim, rather an implementation from scratch.
Edit: Looks like I'm wrong about neovim not being a fork of vim.
It's not an implementation from scratch, do you know the history of the projects?
Neovim started out as a large clean up and refactor of Vim code, plus the addition of async code.
That's a huge amount of work, partially re-implemented by Vim (Bram implemented his own version of async).
Actually, after the Neovim launch a lot of the Vim features were just Bram chasing after Neovim features. Vim9script, :term, etc.
I think there was bad blood there with Bram, I'm not sure how deep the emotional rift was between the 2 groups. From the outside a lot of it looked like stubbornness on the Vim side, at least 60% of the time..
I don't think there was bad blood with Bram. Rather, vim was always Bram's baby, even with contributions from the community, and he was very opinionated about how things should be implemented. IIRC, he found the new features of neovim interesting enough to want to implement them his own way, and a couple times commented that he thought that neovim's approach to certain features was "wrong," to his way of thinking.
His choices were always a bit idiosyncratic, but the success of vim justified them, so it was never a problem... until he died, and now there are two projects, one of which is very modern, both in terms of the codebase and how the project is managed, and the other is likely to become something of a legacy project unless someone as dedicated as Bram is found to take over.
>Neovim started out as a large clean up and refactor of Vim code, plus the addition of async code.
I don't think that is actually true.
As far as I remember Justin and Thiago (I think) wanted to implement the ':term' into vim and Bram just shut them off because he didn't wanted to lead Vim into the road that Emacs went.
And this was what prompted the Neovim fork. And they took the oportunity to also make a big refactor in the codebase.
It was async that Justin and Thiago tried to add to vim, and spent several months wrestling with Bram to get their patch included. At the end, they concluded that they weren't going to get it in and that a fork was necessary. Including the terminal followed quickly after neovim was set up and organized.
> Neovim is a refactor, and sometimes redactor, in the tradition of Vim (which itself derives from Stevie). It is not a rewrite but a continuation and extension of Vim.
These types of mergers have occurred in the past and it usually is the dominant project adopting the use and feel of the features the other has different. Shells acting differently depending on how you call them, for example.
I am not sure how you reconcile some of the philosophical differences between the projects. One of the first objectives of NeoVIM was to dump code for obsolete computing platforms. A ton of legacy code was deliberately removed so as to streamline the project.
If I recall correctly, one of the reasons the original async patch was ostensibly rejected was because it would rely on a C89(?) compiler. That was considered too disruptive a change that would make Vim accessible on fewer platforms.
It’s brutal to say it, but often you handle it by some of the people involved passing away.
Even if neovim basically takes over the older vim code wouldn’t disappear, so it would continue to exist for older platforms. People still keep certain versions of GCC around for similar reasons.
async is water under the bridge since Vim 8, both Neovim and Vim have async apis. I foresee native LSP and everything-lua to be a bigger schism between Neovim and Vim.
Also the deliberate lack of GUI for neovim. The currently extant neovim GUI shells are all universally broken, and some of them crash more than they run. I have yet to find one that is remotely as good as MacVim on macOS. I suspect that most of them are merely tolerable on Linux and some might be barely acceptable on Windows.
With their recent release a few days ago, Neovide has become my daily driver for Neovim on my personal cpu. It were definitely rough edges a few versions ago, but I’m rather pleased where they are now.
I find a lot of Rust GUI projects are slow-going but this has had a good pace
I’ll try it again in a few months, because it was completely unusable on macOS last time I tried it in March. At the moment, I have no time for something that may not work when MacVim works pretty much perfectly for me.
I’ve tried so many different nvim GUIs, but when I last tried them (March or so), none of them behaved correctly on macOS, most of them had atrocious font rendering, didn't like part of the configuration that I had set up (neovide in particular had a deep incompatibility with one of the alert replacement plugins), crashed regularly, or had things enabled by default which aren't reachable with vim scripting.
I’ve gone all in and have converted my vim config to Lua and all…and I have decided that don't like Lua for configuration (there's a massive impedance mismatch between neovim and Lua; you always feel like you're working with a foreign interface).
Goneovim was slightly more stable, but IIRC, the font rendering and macOS integration were awful enough that I uninstalled it shortly after launching it. Neovide lasted slightly longer (so that I could see that plugin incompatibility). VimR tried, but it isn't MacVim.
And that's the problem: they aren't MacVim, providing a native macOS experience on top of a native vim GUI, because the neovim leadership cabal, in their infinite wisdom, decided that a first-party GUI is "useless".
> (there's a massive impedance mismatch between neovim and Lua; you always feel like you're working with a foreign interface).
I agree, and it's a bit surprising that it isn't talked about more. I still feel like it's overall a win compared to Vimscript, in terms of readability and maintainability, but there's definitely an enduring awkwardness to customizing the editor using Lua.
> Goneovim was slightly more stable, but IIRC, the font rendering and macOS integration were awful enough that I uninstalled it shortly after launching it.
That's fair enough - I used it on Linux, and I don't care too much about font rendering, so it works out for me.
Even if the fork doesn't heal, if they could align the code bases to bring them closer, both sides win.