As for neovim, personally, I don't find a reason to switch. They say integrated LSP is coming in their next release but I don't see how that approach could be better than CoC's tracking of VSCode as upstream and bringing all the goodies of that high man-hours product.
What makes me consider switching, is a practical exclusive feature like that Tree-Sitter algorithm for syntax-highlighting that neovim team is touting or at least a concrete and reproducible performance benchmark against the regular vim in their usecase scenarios (startup-time, long logs, diffs, binary editing, etc).
$ cat loop.vim
let sum = 0
for i in range(1, 2999999)
let sum += i
$ cat fold.vim
call eval(join(range(1, 2999999), '+'))
$ time vim -u NONE -S loop.vim
vim -u NONE -S loop.vim 7.08s user 0.09s system 99% cpu 7.198 total
$ time vim -u NONE -S fold.vim
vim -u NONE -S fold.vim 2.03s user 0.13s system 99% cpu 2.166 total
• CPython 3.9.1 segfaults on a direct port of fold.vim after a few seconds. (It generates the 22,888,887-character `1+2+3+…+2999999` string in mostly under a second, then hits a stack overflow in the eval() call, presumably in parsing.)
• CPython 3.9.1 completes it with a loop in under a second;
• CPython 3.9.1 completes it with functools.reduce in half a second;
• CPython 3.9.1 completes it using sum() in about 150ms;
• Node.js 15.6.0 completes it with a loop in about 150ms;
• Node.js 15.6.0 with --jitless completes it with a loop within 300ms;
• Perl 5.32 completes it with a C-style loop in under 300ms;
• Perl 5.32 completes it with a foreach loop on a range in about 160ms;
• Perl 5.32 completes it with List::Util::sum in about 600ms.
So yeah, other scripting languages’ alternatives are pretty much just 5–20× as fast across the board, and often even more than that—and worse still, the performance pitfalls in Vimscript are often not what someone familiar with performance might expect—few would expect your fold.vim to be faster than your loop.vim.
Vimscript is routinely painfully slow to the point that it can easily be a serious bottleneck on anything involved, e.g. a fancy indent script, or some script that you use to process a file.
That said the approach Neovim took of shipping Lua built-in addresses the same portability/ease/reliability of use. In retrospect I think this is a better course of action.
Vimscript feels like a configuration file format gone wild (probably because it's sort of what it is) and it's really annoying to use in my experience. Coming from Emacs it was really a bad surprise: say what you want about elisp, it at least feels like a proper programming language.
NeoVim is using Lua for this very reason. It fits the bill nicely, and is quite fast.
Personally I think the fork to NeoVim was a good thing, giving us an alternative to Vim, and that convergence in itself is not necessarily a goal.
Just like with how I am happy that macOS, FreeBSD, and Linux all exist for me to use, and that Windows exists for others to use. Imagine if the whole world decided that only Windows should exist. I would not want to go back to Windows. Yet at the same time I recognize that Windows is the best choice for many other people.
Same way here, I switched to NeoVim, but I am happy that Vim continues to exist. Just like I am happy that CLion exists which I also use, and I am happy that other people have emacs and Visual Studio and VS Code and all of the other editors and IDEs.
My only real interaction was a few years ago when I opened a doc typo PR, and received a quick response from Bram. Then it faded away again.
Bash is like something that just materialize itself into existence everywhere.
It is very unfortunate that they could not find an agreement.
I think that every open source project used by thousands of people should have person like Bram. Who will draw a line and separate low quality or effort PRs. Many hate it and call them dictators, but that's just taking care of your own project, and keeping it at the highest standard.
“Keep me alive” 
Other than one solitary commit, that graph makes it look like every single one of the 13,000 commits to Vim has been made by Bram. What's going on there?
Incidentally I wondered what caused the huge jump in commits that has been sustained since the beginning of 2016. I thought initially that may have coincided with the announcement of Neovim, but that announcement seems to have been a couple of years earlier. Maybe it took a couple of years for Neovim to see significant adoption though.
I like this approach better than GitHub “everyone send us a PR”. These days having a “change a typo” PR to show activity on GitHub is appealing to masses, but mailing list sifts out people who don’t have anything serious to add = less work in managing open source project. As we can see lot’s of maintainers have a problem with that, and users that demand stuff (at least once a month there’s a topic about it on HN). :-)
I greatly appreciate Vim’s stability. But it’s also not only Bram that can develop it, especially on maintenance patches (as distinct from new features). I can’t think of any particular times anything regressed in Vim, except that I have a feeling there was one. A few times over the years I’ve found bugs, and each time, I’ve either submitted a patch which has been rapidly accepted, or reported the bug and it’s been fixed rapidly by Bram or someone else.
If you’re actually proficient with vim and you’ve tried neovim, than you know that the “shiny” is quickly overcome by the lack of core functions and system integration that makes vim a power tool to begin with.
If you want to use neovim, then you don’t understand what makes vim great in the first place. Here’s a hint: it’s not the key bindings.
And, the maintainers don’t care. They refuse to fix years-old bugs and feature requests. I believe it’s because they’ve painted themselves into a corner with their inexperience and lack of pragmatism.
Because it’s worth giving an example of its glaring mistakes, open up neovim in the terminal and “:!python” ... huh, doesn’t work ... that’s because neovim doesn’t have shell IO from processes it launches. When I googled the issue I found a feature request from 2013-ish. I can’t say anything now, because when I bumped the issue I was told that “ThIS ISn’T a cOre FeatURe, gvim diDn’T haVe THIs uNTil ...” and they closed the feature request at that. No fix, just a “f-u-very much” and the door. I had already posted a few other bug reports / feature requests, but promptly deleted them after that response. I’m done with neovim, except for recommendations that nobody use it.
Use real vim. Donate to help Uganda. https://iccf.nl/news.html
Edit: I missed the hidden comment the first time around. For those that can't log in:
I’m not confident I know just what’s meant by “gvim did not support this until 1-2 years ago”. Opening the command in a Vim terminal, sure, that’s recent functionality (as is the whole concept of a Vim terminal), and opt-in at that, but on MS-Windows at least, from time immemorial :! opened the command in a separate console window, meaning it always worked. Not sure what it does on other platforms, as I’ve long used terminal Vim exclusively.
Also it sounds like they haven’t actually fixed this, just implemented the equivalent of Vim’s guioptions+=!, which… well, that’s definitely not how I want it to work.
They are arrogant, and you’re welcome to not take my word for it. And, I will use continue real vim.
Also, I will continue to disparage neovim. And, the issue still is not resolved. I will also continue to not give a fuck what they do.
I was looking for more pointers on the later, I wrote a little on using Vim Wiki for managing todo list, always on the look out for more tips.
Here's the TLDR;
- Install Vim wiki plugin
- Convert line to checkboxes using ctrl-space
- Use ctrl-space to mark complete
- Use gln to toggle partial complete (glp for previous)
- gl<Space> to remove checkbox
A little more at:
Note: Your .vimrc link in configuration¹ is broken.
Edit: After re-reading my comment it sounds like a complaint, it wasn't meant that way and I hope it didn't come across that way. I did enjoy reading your series!
I updated the link too, I switch back and forth between vim/neovim, the only real difference to me is the location of the config file.
> Re-write the code so that the highlighting isn't changed multiple times when doing a ":hi clear". The color changes happen three or more times currently. This is very obvious on a 66Mhz 486.
While it wouldn't surprise me if some people were still using Vim on 66Mhz 486 machines I would be surprised if anybody bothered to implement this optimization for such a niche use case.
> When a register contains illegal bytes, writing viminfo in utf-8 and reading it back doesn't result in utf-8. (Devin Bayer)