I love vim and I’m happy Chris stepped in to save the project, his vim CSV plugin is something I use daily. Though I really hope vim and neovim merge, I don’t see a reason for the two projects to stay separate.
I doubt many 1980s mainframes were ever capable of running vim. People on 80s mainframes generally used mainframe text editors such as ISPF Edit (on MVS) or XEDIT (on VM/CMS)
Vim’s makefile does have support in it for compiling on Amdahl UTS, Amdahl’s Unix port for IBM-compatible mainframes, and so possibly vim could have run on an 80s mainframe running UTS. However, I’m sceptical there are any mainframes left running UTS anywhere on this planet-nobody uses it in production any more (apparently the last production users were some US telcos in the first decade of this century). I doubt any of the small number of still-working 80s/90s IBM(-compatible) mainframe systems in hobbyist or museum hands run it. There is a version available online you can run in an emulator, but it is an ancient version from the 1970s, whereas I believe the vim port is to a newer 1990s version-and I don’t believe any of those newer UTS versions are publicly available-either they survive in some private collection, or they’ve already been lost to the sands of time.
Nailed it. Bram made the decision on his own and vim's fate is stuck with it. I was bitter about it but now I think it's best for both communities.
Not likely. The directions for the projects seem pretty distinct.
It should be noted that some original vi are still installed by default when installing some OSs.
The whole idea that a project needs to be in constant new-feature mode is just not reality. Just as one example: I'm still using the fluxbox desktop (about 25 years now), and it still meets my top level GUI needs for interacting with my workstation. I don't really _want_ it to change. I want the UI to be exactly the same after an update, so as not to disrupt my workflow.
Just like vim replaced vi, neovim will gradually replace vim. Being maintenance-mode software means only greybeards (and some stubborn holdouts) will stick to it over time and as greybeards retire, the new maintainers of linux distributions who are more familiar with neovim will make their choice.
What might be a big difference though and a big enough stumbling block to prevent merging is the fact that neovim code base has been refactored extensively and updated. Having worked in a big project that was refactored without me, and then returned, it is actually worse than a new code base because you feel like you should know where things are, but they aren't there. It continually misleads you and wastes your time. I could see that frustration being enough to keep the them proper people from merging or moving to neovim.
Vim is expected to continue to work everywhere, even on some bank's circa 1980 mainframe. NeoVIM has become an effort to revitalize the project. Support for ancient systems was tossed almost immediately (eg no more 8.3 filename support code). NeoVIM also included some much improved default configuration values.
Continuity I get, but how much are we collectively burdened by having a few ancient uses determine the wants of the many?
Lots of designs from the past can no longer connect to the internet in a meaningfull capacity but new hardware today might meaningfully last far longer than the developers could even anticipate.
It's not that I actively hate anything that isn't a recent 64-bit Unix, but that the people on other systems are either 1) hobbyists who are competent to port stuff to their own systems, or 2) companies who aren't paying me for extraordinary support.
Bummer if something I wrote last week doesn't run on HP-UX, but it's not going to cost me sleep.
Because of neovim and the power of forking, essentially nothing. The ones who favor stability choose one program, the ones who favor bleeding-edge chooses another that matches.
Also you probably want ed (the standard text editor) for POSIX compliance. (Fun fact, vi is not required by POSIX, so you will not find it on every single POSIX compliant host.)
This seems very unlikely. In neovim help docs there's a paragraph in file `nvim.txt`
Nvim is emphatically a fork of Vim, not a clone:
compatibility with Vim (especially editor and Vimscript
features) is maintained where possible. See |vim
differences| for the complete reference of differencesfrom
Vim.
I hope that if they do merge that the connection to ICCF Holland is maintained.
Every time you start vim (without specifying a file) you see the message "Help poor children in Uganda!". It's been a salutary thing over the years to see Bram building something as amazing as vim and maintaining the commitment to helping orphaned kids in Uganda, I would be sad if that disappeared under the neovim bus.
If you're a vim user and you'd like to support Bram's vision, here's the link https://iccf-holland.org/donate.html .