On Vim’s being institutionally outdated

I adore Vim, I use it every day, and I wouldn’t dream of switching to anything else, but every once in a while I’m reminded of another thing about it that is just unequivocally bad and indefensible.

I was reading about the “CoC” plugin (“Conqueror of Completion”) this morning when I thought, “Wait, can’t Omni completion do some of that?” So I opened up Vim with a minimal .vimrc and typed:

document.que<C-x><C-o>

<C-x><C-o> opens Vim’s native Omni completion function, which I would expect to be at least somewhat current on JavaScript methods in 2020. Instead, nothing came up.

I had a look at the source of the JavaScript completion function in Vim, and found this: a file that was last updated three years ago, but that hasn’t been meaningfully updated since 2006.

So how have Vim users been getting by?

As far as I can tell, Vim users who want JavaScript completion have been using a plugin called vim-better-javascript-completion, which has a history of exactly 0 pull requests and hasn’t been updated since 2016. Not only are Vim users turning to a plugin for something that should be native (I’ve seen this elsewhere with other languages, too), but that plugin is effectively inactive.

You might be thinking, Well why not just submit a PR to Vim’s native JavaScript completion file?

Vim doesn’t accept PRs as commonly understood. For one, if you do submit a PR, there is no team of people that might review it and merge it; there is only Bram Moolenaar, Vim’s Benevolent Dictator for Life. Second, this will not happen via standard VCS channels; Bram will write his own patch based on your work, if and when he gets around to it.

Additionally, in the case of syntax- and language-oriented Vim components, an interested contributor is instructed to contact the “maintainer,” typically indicated in the header of a Vim file with an email address and/or URL. In the case of JavaScript completion, that maintainer has a minimal GitHub presence; ideally, the file would be hosted as a repository on his Git host of choice, open for PRs, but this is not the case. I will have to email him to get anything done, on a core JavaScript component within vanilla Vim that hasn’t been updated in at least 14 years.

(I mean absolutely no ill will against this maintainer, or Bram for that matter. Contributing to open source is often thankless work done on evenings and weekends, though I do believe the processes around such a vital editor could be improved.)

Ah!, you might now be thinking, But what about Neovim?

Regrettably Neovim uses the exact same ancient JavaScript completion file from Vim. But surely Neovim accepts PRs in a conventional way? I’m afraid not. After submitting an extremely modest PR to add some basic JavaScript methods to Neovim, I was told once again to contact the maintainer, who will (in theory) accept or reject my suggestions, send those to Bram (not via PR, of course), who then might, might add them to Vim.


I’m certainly no expert, but I would love to see four things happen to Vim:

  1. Bram: Find two people you trust to review PRs, and merge them as PRs.
  2. Syntax and language file maintainers: Put your files in a GitHub repo and open them to PRs.
  3. Neovim: More aggressively question your dependencies on upstream Vim for progress.
  4. Plugin writers: Consider submitting your “improved language support” plugins to core Vim, rather than forking core functionality and perpetuating a dependency on plugins.

I sometimes get defensive when people say that Vim users are crazy or have stockholm syndrome, but sometimes I think they might be right.

Leave a Reply

Your email address will not be published. Required fields are marked *