For anyone who is new to vim and wants a more-or-less OOTB auto-complete, auto-format experience, I recommend https://github.com/neoclide/coc.nvim
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).
Neovim started out as a quite interesting project but now I don't see a reason to use it. Not that I think it was pointless for the project to start in the first place. The competition seemed to motivate Vim devs to make advancements.
I'm really not a fan of the decision to overhaul Vim script. It seems this is driven from a desire for Vim script to be faster [1]. I've not needed Vim script to be "faster" but I don't use very complex plugins. That said a lot of Vim script is written in sub-optimally. Using a more functional approach is faster (though still not "fast"), e.g.
$ cat loop.vim
let sum = 0
for i in range(1, 2999999)
let sum += i
endfor
quit
$ cat fold.vim
call eval(join(range(1, 2999999), '+'))
quit
$ 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
I think its cryptic reputation comes form the use of normal mode commands and regex within scripts. There certainly are warts, like the user's 'ignorecase' setting permeating to many places in the runtime. Which I'd love to see fixed and whilst may also represent a breaking change for some scripts would be far more easily adoptable.
Meanwhile, on a computer that’s benchmarking within 20% of your figures:
• 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.
(I didn’t try porting fold.vim to JavaScript because it lacks the primitives to make that a sane operation; or Perl, because my Perl skills are rusty enough that it would take a few minutes to sort it out, and I was lazy.)
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.
I know nothing about Vim script, but since they're overhauling it, wouldn't it be a better option to rely on python scripting by providing a plugin API? Of course there's backwards compatibility, but they could always support both for a few years. Having to support your own language always seemed like a waste of time to me.
See the "PHASING OUT INTERFACES" section of the link in my comment for Vim's reasoning of moving away from this. Personally I broadly agree with it as I've seen many people struggle setting up plugins that depend on other things like python.
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.
I agree. I haven't given Neovim a chance yet and I'm not a huge fan of Lua but it would certainly be a pretty good upgrade compared to clunky Vimscript.
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.
Overhauling vim script feels forced by Neovim's successful integration of Lua. But instead of adopting a sane language, or adopting Lua so Vim and Neovim can continue to be compatible, he decided to write yet another homebrew language.
I'm on the fence about this, I don't think Bram or other Vim devs are malicious towards Neovim. But the repeated implementation of equivalent features with incompatible APIs (terminals, async, and now faster scripting) doesn't look good.
I think it is useful to keep in mind that Vim has been around since 1991. And in light of that I can see how Bram and the other devs may have a very different view on where the future of Vim should be from where the NeoVim authors think that NeoVim should go.
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.
I just realized that, even though I use vim every day and work on open-source software for a living, I have no idea what vim's open source model looks like. It's been such an out-of-the-way tool for me that I treat it like a pencil. It's just there, waiting for me to use it.
Pretty much my experience too. Every few months my distro collects up a bag of patches, then I receive a new build. Once every couple of years I get to go through a version${new}.txt help file, often receiving a few new goodies.
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.
From my understanding they forked it over disagreement for terminal implementation in VIM based on bunch of unfinished code. Which Bram didn’t wanted to add until it’s properly implemented.
I did a PR regarding some rarely-used setting a couple of years ago, as part of a uni course in architecture. It wasn't merged immediately as I didn't write tests for it, but Moolenaar wrote the tests himself later, and merged it.
I see huge amount of PR merged with VIM on daily basis send by other people.
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.
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.
Patches are send to mailing list, and Bram commits them do repository after review. Each contribution is credited in commit message, and VIM docs.
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). :-)
Thank you. Having a mailing list based workflow is fairly common for long established projects. That doesn't seem to preclude setting the Author field to the actual author when Bram lands people's contributions though. Unless that's an additional layer to discourage low value contributions by eliminating the visible credit people would get in their github commit history. Are there other projects that do that?
As I mention before, each of contributions is credited on GitHub commits, and VIM docs. So you still can showcase those in your portfolio, by writing case study or short information as it was before GitHub... :-)
As one who depends implicitly on Vim, he seems to me very benevolent: he doesn’t let other people break Vim.
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.
TL;DR; neovim is garbage and the maintainers are arrogant. It’s a project that can’t die soon enough.
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.
I have never used NeoVim, but I am genuinely flabbergasted at the idea of not considering it a bug that :! is not interactive. I would consider that very close to fundamental functionality; I know that lacking it would make me stumble from time to time, and I’ve seen various other Vim users and plugins depend on it not irregularly also.
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.
Nice doc series. Perhaps consider linking your lines documentation in the todo docs as an example of how to shift items around? Every time vimwiki/todo.txt comes up here people bring up how to move/delete completed items, often because they're unaware of :move and friends.
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!
Note that many of these entries seem pretty old and are probably "wontfix" in practice. This one stood out to me:
> 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.
Remember vim's first release date is 1991. What other ~30 year-old non-niche software do you know that has managed to remain relevant and having people actively developing for it?
vimscript is unfortunately way too limited for this sort of tasks. I wish they had the todo list to replace it with something a bit more elegant, not goign as far as lisp or scheme but even lua or python
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).