7 ms·

I do hope this gets taken as a chance to merge Vim and Neovim, otherwise a divided community is not great for the editor

ctenb 3y ago
Yes, although the forks have diverged quite a bit by now :(
- oblio 3y ago
  True, but if there's a will, there's a way. They can compromise on the process and maybe aim for a medium to long term merge. I.e. they start aligning coding conventions, standards, etc, and when they're ready 1-2 years from now they pull the switch and re-merge the code bases.
  - halostatue 3y ago
    There is one thing that vim provides that the neovim folks have said that they will never provide, and that’s a GUI. Unless the vim project gives that up (and there will be significant outrage over that), or unless the neovim folks give up that particularly shortsighted stance (having a first-party cross-platform pluggable GUI is a good thing), I do not see a merge ever happening.
kzrdude 3y ago
Why not? vim and neovim have been separate for a long time already, wouldn't it work to continue like that?
- meitham 3y ago
  There’s no future to Vim without Bram. A merge of the two fork’s isn’t what Bram has wanted, but it’s the best way to keep Vim alive
  - oblio 3y ago
    I wouldn't be so dismissive. Vim is a marquee project, tons of hackers will want to contribute because it's cool or because they want to have that name on their CV.
    - krossitalk 3y ago
      Pretty much this. I'd like to take a crack at updating that vim.org page away from PHP5/MySQL.
    - The_Colonel 3y ago
      > tons of hackers will want to contribute because it's cool It's one thing to contribute a couple of PRs/patches, a very different thing to spend a large part of your free time on the project for years (which is what Bram did to make vim what it is). These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it.
      - ftaghn 3y ago
        > These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it. Those same contributors that remained on vim instead of neovim didn't put much effort into vim9 ecosystem either. I can't imagine them being willing to maintain all of vim's baggage when literally nobody writes vim9script. Classic vimmers tend to stick to the old vimscript. As you said, contributing a few patches to classic vim is one thing, but becoming an actual maintainer of the behemoth that comes with a ton of useless baggage is a whole another thing. Maintaining a programming language no one uses.. sisyphus would be proud.
  - GneissFrog 3y ago
    No future for Vim without Bram? People said the same thing about Apple when Steve Jobs passed away. Turns out, as long as you have loyal users and competent people working, things can keep on chugging right along. It seems a bit ridiculous to dismiss reunification when you don't even know what kind of compromises might be made to make it happen.
- oblio 3y ago
  If the project leads can agree to a shared vision - which frankly should be similar considering the scope of the projects - it's most likely better if they merge. Open Source projects never have enough resources and splitting them into 2 clone projects is generally not great. I know about competition but it's not like Vim/Neovim, programming text editor, is lacking in competition even without the other side of the fork :-)
  - tokai 3y ago
    >better if they merge You and meitham are very focused on this, but it is very much an opinion and not a fact.
    - nicce 3y ago
      It depends on the differences of their goals and principles. It is fact that 1 + 1 > 1 if you compare available resources.
      - kzrdude 3y ago
        Vim was developed by Bram commiting and controlling every change. Neovim very much already unlocked a greater than one situation by adopting a different development model.
    - oblio 3y ago
      It is an opinion backed by watching Open Source projects for several decades. Long lived forks are rarely good for an individual project. Frankly, the most successful forks I've seen unfortunately... kind of strangle off the original. Jenkins/Huson, LibreOffice/OpenOffice, MariaDB/MySQL, ConsoleZ/Console2/... Though there are cases where the original wins out: Emacs/XEmacs, etc. Especially since it's not like Vim/Neovim are already lacking in features to implement, bugs to fix, ways to extend their architectures :-)
      - tokai 3y ago
        Eh I'm not going to go through your list, but putting libre/open office on there is disingenuous. Open office was run into the ground by Oracle, not because of the forking.
nerdponx 3y ago
They're already getting to the point of being two different editors with a common lineage and legacy support for Vimscript. The Neovim people also probably don't want to re-merge with Vim, it would probably have to be Vim basically winding down development. Doesn't seem likely.
- bhaak 3y ago
  > They're already getting to the point of being two different editors with a common lineage and legacy support for Vimscript. Let's see how much traction Vimscript9 will get. From the distant view of an outsider I got strong NIH vibes from that. > it would probably have to be Vim basically winding down development. Doesn't seem likely. It depends on how much Bram was the main focus point of development and if the remaining contributors are able to transition to a less centric development structure. I would rather expect a EGCS/GCC "merger" than a true code merger. But only time will tell.
  - ftaghn 3y ago
    > Let's see how much traction Vimscript9 will get. In practice, none. It's a wasteland. Extensions that aim to be compatible with both vim / neovim use the old vimscript, while lua has very, very significant traction in the neovim world among people who try to bring IDE like feature to vim. The amount of people willing to write extensions that only work on vim proper, which is what would happen if they used vim9script, is close to non existent. > I would rather expect a EGCS/GCC "merger" Or libav vs ffmpeg.
  - Legion 3y ago
    > Let's see how much traction Vimscript9 will get. From the distant view of an outsider I got strong NIH vibes from that. Honestly, that's what most recent Vim development in the Neovim era looks like to me. Bram rejected async patches for years. Neovim gets made and proves out the demand for async. Vim suddenly is motivated to cook up their own, incompatible version of async. When Neovim began, I thought the inevitable future was the Vim project cherry-picking the best features from Neovim each time such a feature reached sufficient maturity and popularity, and merging Neovim's implementations back into the core project. I underestimated how strong the NIH syndrome was with Vim proper.
suprjami 3y ago
I don't. Neovim have dropped "old useless" features which are the entire reason I use Vim.
- djtango 3y ago
  I've not tried neovim mostly because I'm hopelessly loyal. curious what features were cut?
  - suprjami 3y ago
    vim-cscope, which is the only reasonable way to read large C projects like the Linux kernel or BSD
    - School-Cotton 3y ago
      What’s wrong with clangd via lsp?
      - devnullbrain 3y ago
        n.b. LSP support was the reason cscope support was dropped
      - kps 3y ago
        For one thing, LSP (last I checked) was still unable to distinguish between read and write.
      - suprjami 3y ago
        You need to build the project to generate compilation database. I switch around kernel versions far too often for that to be viable.
- random_mutex 3y ago
  What features?
  - 3y ago

ctenb 3y ago

Yes, although the forks have diverged quite a bit by now :(

oblio 3y ago
True, but if there's a will, there's a way. They can compromise on the process and maybe aim for a medium to long term merge. I.e. they start aligning coding conventions, standards, etc, and when they're ready 1-2 years from now they pull the switch and re-merge the code bases.
- halostatue 3y ago
  There is one thing that vim provides that the neovim folks have said that they will never provide, and that’s a GUI. Unless the vim project gives that up (and there will be significant outrage over that), or unless the neovim folks give up that particularly shortsighted stance (having a first-party cross-platform pluggable GUI is a good thing), I do not see a merge ever happening.

kzrdude 3y ago

Why not? vim and neovim have been separate for a long time already, wouldn't it work to continue like that?

meitham 3y ago
There’s no future to Vim without Bram. A merge of the two fork’s isn’t what Bram has wanted, but it’s the best way to keep Vim alive
- oblio 3y ago
  I wouldn't be so dismissive. Vim is a marquee project, tons of hackers will want to contribute because it's cool or because they want to have that name on their CV.
  - krossitalk 3y ago
    Pretty much this. I'd like to take a crack at updating that vim.org page away from PHP5/MySQL.
  - The_Colonel 3y ago
    > tons of hackers will want to contribute because it's cool It's one thing to contribute a couple of PRs/patches, a very different thing to spend a large part of your free time on the project for years (which is what Bram did to make vim what it is). These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it.
    - ftaghn 3y ago
      > These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it. Those same contributors that remained on vim instead of neovim didn't put much effort into vim9 ecosystem either. I can't imagine them being willing to maintain all of vim's baggage when literally nobody writes vim9script. Classic vimmers tend to stick to the old vimscript. As you said, contributing a few patches to classic vim is one thing, but becoming an actual maintainer of the behemoth that comes with a ton of useless baggage is a whole another thing. Maintaining a programming language no one uses.. sisyphus would be proud.
- GneissFrog 3y ago
  No future for Vim without Bram? People said the same thing about Apple when Steve Jobs passed away. Turns out, as long as you have loyal users and competent people working, things can keep on chugging right along. It seems a bit ridiculous to dismiss reunification when you don't even know what kind of compromises might be made to make it happen.
oblio 3y ago
If the project leads can agree to a shared vision - which frankly should be similar considering the scope of the projects - it's most likely better if they merge. Open Source projects never have enough resources and splitting them into 2 clone projects is generally not great. I know about competition but it's not like Vim/Neovim, programming text editor, is lacking in competition even without the other side of the fork :-)
- tokai 3y ago
  >better if they merge You and meitham are very focused on this, but it is very much an opinion and not a fact.
  - nicce 3y ago
    It depends on the differences of their goals and principles. It is fact that 1 + 1 > 1 if you compare available resources.
    - kzrdude 3y ago
      Vim was developed by Bram commiting and controlling every change. Neovim very much already unlocked a greater than one situation by adopting a different development model.
  - oblio 3y ago
    It is an opinion backed by watching Open Source projects for several decades. Long lived forks are rarely good for an individual project. Frankly, the most successful forks I've seen unfortunately... kind of strangle off the original. Jenkins/Huson, LibreOffice/OpenOffice, MariaDB/MySQL, ConsoleZ/Console2/... Though there are cases where the original wins out: Emacs/XEmacs, etc. Especially since it's not like Vim/Neovim are already lacking in features to implement, bugs to fix, ways to extend their architectures :-)
    - tokai 3y ago
      Eh I'm not going to go through your list, but putting libre/open office on there is disingenuous. Open office was run into the ground by Oracle, not because of the forking.

nerdponx 3y ago

They're already getting to the point of being two different editors with a common lineage and legacy support for Vimscript. The Neovim people also probably don't want to re-merge with Vim, it would probably have to be Vim basically winding down development. Doesn't seem likely.

bhaak 3y ago
> They're already getting to the point of being two different editors with a common lineage and legacy support for Vimscript. Let's see how much traction Vimscript9 will get. From the distant view of an outsider I got strong NIH vibes from that. > it would probably have to be Vim basically winding down development. Doesn't seem likely. It depends on how much Bram was the main focus point of development and if the remaining contributors are able to transition to a less centric development structure. I would rather expect a EGCS/GCC "merger" than a true code merger. But only time will tell.
- ftaghn 3y ago
  > Let's see how much traction Vimscript9 will get. In practice, none. It's a wasteland. Extensions that aim to be compatible with both vim / neovim use the old vimscript, while lua has very, very significant traction in the neovim world among people who try to bring IDE like feature to vim. The amount of people willing to write extensions that only work on vim proper, which is what would happen if they used vim9script, is close to non existent. > I would rather expect a EGCS/GCC "merger" Or libav vs ffmpeg.
- Legion 3y ago
  > Let's see how much traction Vimscript9 will get. From the distant view of an outsider I got strong NIH vibes from that. Honestly, that's what most recent Vim development in the Neovim era looks like to me. Bram rejected async patches for years. Neovim gets made and proves out the demand for async. Vim suddenly is motivated to cook up their own, incompatible version of async. When Neovim began, I thought the inevitable future was the Vim project cherry-picking the best features from Neovim each time such a feature reached sufficient maturity and popularity, and merging Neovim's implementations back into the core project. I underestimated how strong the NIH syndrome was with Vim proper.

suprjami 3y ago

I don't. Neovim have dropped "old useless" features which are the entire reason I use Vim.

djtango 3y ago
I've not tried neovim mostly because I'm hopelessly loyal. curious what features were cut?
- suprjami 3y ago
  vim-cscope, which is the only reasonable way to read large C projects like the Linux kernel or BSD
  - School-Cotton 3y ago
    What’s wrong with clangd via lsp?
    - devnullbrain 3y ago
      n.b. LSP support was the reason cscope support was dropped
    - kps 3y ago
      For one thing, LSP (last I checked) was still unable to distinguish between read and write.
    - suprjami 3y ago
      You need to build the project to generate compilation database. I switch around kernel versions far too often for that to be viable.
random_mutex 3y ago
What features?
- 3y ago