Neovim is a continuation of Vim, you can find more info here: https://neovim.io/charter/
Edit: This doesn't mean Vim is discontinued.
Edit: This doesn't mean Vim is discontinued.
Neovim is a hard fork, not a continuation. Vim is still being developed by Bram and other contributors, and has a lot of the same functionality now with different API surfaces. Questionable choices by both development groups (but, IMO, mostly from the initial arrogance of the neovim developers) are increasing the gap to the point where, in a couple of years, I do not expect there to be meaningful compatibility between them.
A lot of people don’t like Vimscript, but I personally find the Lua integrations which neovim has to be harder to use because the language isn’t built around the editor, it requires bridging, and there’s a definite impedance mismatch involved.
For me, without an equivalent of `gvim`/`MacVim`, neovim is a non-starter. The OS-level integration is important, and none of the various neovim GUIs that exist are nearly as good as the original `gvim` for X or Windows or MacVim for macOS.
Vim really was in a sad state prior to the fork which turned out to be a wake up call to Bram it seems.
Bram is top contributor for vim. 16,211 commit right now. Second top most contributor has 194 commits only. Neovim top contributor has 2285 commits, followed by 21,66 commits for second.
It looks to me that neovim is more open to community contribution.
Then look at commit graph over period of time. It looks like Neovim is more actively developed. There development activity level around vim also increased in 2016. Perhaps that was the time when bram realized that he need to do more with vim, to compete with neovim.
I myself was a longtime vim user, who switched to neovim 2 years ago, and am happy with it.
[1] https://github.com/vim/vim/graphs/contributors [2] https://github.com/vim/vim/graphs/contributors
I replied in a different comment (https://news.ycombinator.com/item?id=33922783) about the async patches, which is where the whole things started. Because the patches weren’t accepted as is, they hard forked.
That requires an incredible amount of arrogance.
Neovim is not better than Vim. It is (increasingly) different. They have made different choices, some of which are interesting, some of which are baffling, and most of which are just different, although I consider the removal of GUI support to be about as arrogant as the gemini protocol stuff. There is a pernicious strain of software developer that thinks that they know better on everything and that GUIs are bad.
I felt that way in 1992 or so, despite having been exposed in 1990 to X, because it was easy to pick on Windows 3.1 and (then) Mac users. I got over it because there are things which are better, easier, and faster with GUIs than without. Not everything needs a GUI, but if you want people to use your software, leaving it in the terminal is unlikely to be a long-term success strategy.
Bram wasn't going to add those updates/upgrades (for philosophical reasons). So the community did what OSS does; and forked/added them. NeoVim was born.
Others could (justifiably) contest, but that caused Bram to ~panic that Vim wouldn't be the primary 'vi' moving forward, and Vim updates (adding NeoVim features or equivalents, sometimes better sometimes worse) started coming out.
{Neo,}Vim is in a much better state functionally than it was a few years ago because of the schism; enough that I switched back from VSCode without missing (much). I am saddened by the split community now though.
They didn't just delete the GUI. They made it easy to embed neovim and as a result there are several GUI frontends now. Seems like a good call - gvim is not a great gui so why keep it around rather than making it easy for gui people to make good ones against an api? There are several active guis right now: https://github.com/neovim/neovim/wiki/Related-projects#gui
Given the choice, I can either:
1. Hate every day of working with the substandard state of neovim GUIs
2. Hate every day of working with neovim remediated by a terminal
3. Switch to Emacs
4. Switch to VS Code
or
5. Keep using MacVim, because it just works
I try each of the various active neovim GUIs every few months. Usually, I end up noping out of each one with just trying to edit a single file. For ones that have stuck for a day or two, I end up noping out of them because they are missing key OS integrations or are sluggish or have made decisions to act more like an IDE (Vimr) that result in a UI that’s less flexible than gvim or MacVim itself.
You say that gvim isn’t a great GUI, but that’s a subjective — and IMO wrong — opinion. It is vim. It doesn’t try to be anything but vim. It doesn’t try to add IDE frippery (because you can implement all of that with vim plugins) or switch to an entirely different plugin system where you can’t use any of your existing configuration (Oni2).
gvim — and MacVim — are great GUIs for being separate non-terminal-bound views on vim. There’s not a single neovim GUI that has reached that level, and most of them get abandoned because, in the end, no one on the neovim ecosystem cares because the core project doesn't care.
I would like so suggest you reconsider your priorities - all this anger over something existing is probably bad for your heart.
VimR is very good; I've been using it before it started using Neovim as the core [1].
Before I can take Neovim seriously, I need a Neovim GUI that is exactly what gvim or MacVim provide — not something that adds features I neither want nor need nor can I easily disable.
Granted, it’s been about six months since I’ve used VimR, but I bounce off it every time, because it doesn’t work with the configuration that I have built up trying to match my Vim configuration to the best of my ability.
Having used MacVim for several years and now using Neovim mostly in the terminal but sometimes VimR, I disagree that it's a mess.
I get wanting to have a common gvim ui/ux across platforms, but I think having a Mac-like or Windows-like ui/ux on those platforms mostly trumps that.
Also, the special features of VimR, like the built-in file browser and Markdown preview can easily be disabled. Using the native rendering of macOS and support for ligatures, for example, is certainly a plus IMHO.
They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?
On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.
You have every right to disagree with people's patchset, just as they have every right to disagree with your direction and decide to do it their own way.
The arrogance is twofold:
1. Their way or the highway. It wasn’t that Bram wouldn’t accept their input, but that would not accept Bram’s input and change the patches to be closer to what he wanted for such a feature. He would not accept their input under their arrogant terms.
2. Their continued description of Neovim as a "continuation" of Vim—as if the development of Vim had stagnated (it had not, it just wasn’t at the pace that the Neovim developers wanted). It’s a garbage statement that should have been removed five minutes after it was first stated, unless the person making (and continuing to make) the statement is so arrogant that they can’t see that it’s an outright falsehood.
Frankly? I don’t care that Neovim forked from Vim. IMO, it’s got some interesting ideas overshadowed by a core team that is careless with its language and some of its technical direction (see elsewhere on the treatment of ACLs, which makes neovim fundamentally unsuitable as a system editor). As an editor, I think that it’s less mature and stable than vim. I think that the use of Lua is interesting, but that the Lua/Vim API is less than useful. As an experimental testbed for some neat ideas…good on them.
Could I contribute to neovim to fix some of the issues that I have with it? Sure. I don’t want to, though, because on the whole I find the attitude from the neovim developers to be unwelcoming. That could be fixed by removing unnecessarily inflammatory language and no longer lying about the origins of neovim.
Forks can be good, even if there is no cross-pollenization between the projects. Look at the success of egcs. But they aren’t good when they’re founded on lies and ill will.
I don't mind your indigination -- you've given neovim v. vim more thought than most. I do mind when pointy heads say "I don't care" when they clearly do.
I do care about the way that the fork happened and the misrepresentations of the fork, so I’ve written way too many words about this today.
Or pragmatism?
And as you point out, you still need to know a bunch of viml that you have to wrap in Lua calls.
At the same time, I haven't actually given vim scripting in Lua a fair shot, so I'd be happy if anyone could shed some light on why they might think it's better.
Neovim was never a continuation. Bram has never stopped developing Vim.
As I understand it, the people behind Neovim developed some async patches which were not accepted by Bram for various reasons, and there was an ongoing discussion. Rather than reworking them to something that Bram thought was acceptable, they performed a hard fork. In the process of hard forking, they removed everything that they considered unimportant. This included gvim, support for older OSes, etc.
Vim has not, to the best of my knowledge, copied any features back from neovim, although it does now (shortly after Neovim forked) have async features (written with an API and user surface that Bram prefers) and various other features that may be similar.
Please note that Vim has had Lua, Ruby, Python, Perl, and other scripting language support for a very long time. The main difference is that rather than being compiled as an add-on and using bridging, neovim has added a Lua engine into the core (increasing complexity that way) and creating a DX-poor bridge for common vim configuration things so that startup scripts can be written in Lua.
Yes, Bram started working on Vimscript9 late, but your characterization of the history also is (unintentionally?) dishonest in that Vimscript has had extensive expansion and updates through time.
Neovim is not and has never been a continuation of the Vim project, despite their press. It has always been a hard fork that is getting increasingly incompatible with the source project, and I personally find it less usable than Vim because there’s not a single good GUI for it (there are several which may eventually become promising, and there are several which have taken bizarre directions like Oni2 did).
And one can look at the explosion of new Lua-based plugins that have been developed because of it. People hated Vimscript. Now that there is a better first class language (guaranteed! Not dependent upon the host environment or compilation target), NeoVim is gaining some of the plug-in functionality that had previously been Emacs exclusive.
Edit: fixed autocorrect
vimscript9, terminal, async among others. NeoVim was a kick in the pants for Bram to pull Vim into modernity.
Neovim provided Bram competition, but he has not copied those features from Neovim.
vimscript9 doesn’t look or act like Lua (it still acts like a first-class citizen, unlike Lua) even though it is definitely improved over the previous version.
There have been terminal scripts for a while, but adding virtual terminal support was something resisted because a lot of people ran vim in a tty or with tmux. (Strictly speaking, terminal support is only something that to me makes sense for gvim and the like, otherwise you’re getting into terminal emulators all the way down. So much for the neovim philosophy of ripping unnecessary things out.)
And async was the entire reason that Neovim hard forked from Vim. Bram did not like the patches and asked for changes. The Neovim developers didn’t like the changes, so they hard forked. Bram implemented the async features / API surface that he wanted shortly thereafter.
There is a constant push from the Neovim camp that Vim is stagnant, backwards, dead, etc. None of this is true, and the messaging should absolutely stop. Frankly, I’d be happier if they rebranded from Neovim, because IMO they’re not vim and have stopped caring about compatibility with vim.
I have happily used (Brams) Vim the majority of my career; some daliances into PyCharm or VSCode here and there.Prior to the NeoVim fork; Vim felt.. slow.. to adopt new features. I was OK with that generally. 5 years for Vim7 to come out was the biggest gap, before Vim8 released after a decade gap (with NeoVim getting forked ~halfway through). Each major release taking longer than the previous. You can say Vim development hadn't slowed; but major releases did; with a ten year gap was concerning.
I don't say that as a negative on Bram, but 10 years between major releases is an eternity in the modern programming world - I'm glad he's refocused, Vim-9 is a huge leap forward.
Terminal is what allows plugins such as fzf.vim to work, I think it's amazing.
I only welcome the competition between vim and neovim, I think it's been a great improvement to the ecosystem.
The API is pretty well documented now I think? If there is a specific area that isn't, then file a bug or write the docs. It is an open source project and thus is heavily depends on people contributing to make things better.
Vimscript9 fixes some of this, but it is still focused on being a special purpose language (scripting vim) far more than being a general purpose language.
I agree with you that the neovim / Lua bridge is substandard and poorly documented, and way too magic. There’s too much distance between Lua and the vim model that isn’t well bridged by the API that has been written.
Certain things are better for neovim with Lua, because you can (in theory) take advantage of all that Lua has via luarocks. But that bridge back to the editor is still ugly, and I don’t like it.
What features do you use from gvim? I used to switch between them, but I hated updating the vim font when I decided to change my terminal font, so eventually I just switched to the terminal version full-time. It's been over 10 years at this point, but I don't remember anything useful in gvim.
I’m using MacVim as my gvim, but as I’ve indicated, the amount of code in MacVim is fairly small over that in gvim.
I don't especially like Lua as a language (it's okay-ish, I guess, but not great), and I certainly don't think it's a good fit for a Vim configuration language, but it's okay to disagree on that. But it seems that some people are unable to comprehend that some people don't think that Lua is a gift from heaven for Vim.
Vim9Script is very similar to "legacy VimScript", but with slightly different syntax and typing. Overall, I'd say is less of a breaking change than Python 3 was, and it's not like Python 3 is a "new language": just a continuation of the >20 years of Python 1 and 2 before it.