3 ms·

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 i

by goku12 3y ago

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.

bombcar 3y ago
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.
- 0cf8612b2e1e 3y ago
  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.
  - bombcar 3y ago
    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. Or you abuse the preprocessor and automake.
    - oblio 3y ago
      Science advances...
  - Aissen 3y ago
    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.
    - halostatue 3y ago
      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.
      - imbnwa 3y ago
        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
        halostatue 3y ago
        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.
        sundarurfriend 3y ago
        I've generally had more success with Goneovim than with Neovide, give that a try if you haven't yet.
        halostatue 3y ago
        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".
  - rolisz 3y ago
    I think very, very, very few people still care about the C89 compiler. A bigger blocker to a merge/collaboration would be the move to use Lua in neovim
AlecSchueler 3y ago
Are you sure it's not a fork? From their project wiki: > Neovim is a project that seeks to aggressively refactor Vim source code > It is important to emphasize that this is not a project to rewrite Vim from scratch
biorach 3y ago
No, Neovim is a fork > 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. https://neovim.io/charter/ https://neovim.io/charter/
oblio 3y ago
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..
- kzrdude 3y ago
  Bram evidently had his own way, since he didn't let anyone else make commits to the project. That's fair, and in that situation forks are expected.
  - rmwaite 3y ago
    I’ve seen some reports that he did allow commits but he would “re”-commit them as part of his workflow. I’m not sure about the reasoning there.
- nzach 3y ago
  >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.
  - fatbird 3y ago
    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.

by goku12 3y ago

bombcar 3y ago

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.

0cf8612b2e1e 3y ago
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.
- bombcar 3y ago
  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. Or you abuse the preprocessor and automake.
  - oblio 3y ago
    Science advances...
- Aissen 3y ago
  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.
  - halostatue 3y ago
    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.
    - imbnwa 3y ago
      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
      - halostatue 3y ago
        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.
        sundarurfriend 3y ago
        I've generally had more success with Goneovim than with Neovide, give that a try if you haven't yet.
        halostatue 3y ago
        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".
- rolisz 3y ago
  I think very, very, very few people still care about the C89 compiler. A bigger blocker to a merge/collaboration would be the move to use Lua in neovim

AlecSchueler 3y ago

Are you sure it's not a fork? From their project wiki: > Neovim is a project that seeks to aggressively refactor Vim source code > It is important to emphasize that this is not a project to rewrite Vim from scratch

biorach 3y ago

No, Neovim is a fork > 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. https://neovim.io/charter/ https://neovim.io/charter/

oblio 3y ago

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

kzrdude 3y ago
Bram evidently had his own way, since he didn't let anyone else make commits to the project. That's fair, and in that situation forks are expected.
- rmwaite 3y ago
  I’ve seen some reports that he did allow commits but he would “re”-commit them as part of his workflow. I’m not sure about the reasoning there.
nzach 3y ago
>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.
- fatbird 3y ago
  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.