On Vim’s being institutionally outdated

I adore Vim, I use it every day, and I wouldn’t dream of switch­ing to any­thing else, but every once in a while I’m remind­ed of anoth­er thing about it that is just unequiv­o­cal­ly bad and inde­fen­si­ble.

I was read­ing about the “CoC” plu­g­in (“Con­queror of Com­ple­tion”) this morn­ing when I thought, “Wait, can’t Omni com­ple­tion do some of that?” So I opened up Vim with a min­i­mal .vimrc and typed:

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

<C-x><C-o> opens Vim’s native Omni com­ple­tion func­tion, which I would expect to be at least some­what cur­rent on JavaScript meth­ods in 2020. Instead, noth­ing came up.

I had a look at the source of the JavaScript com­ple­tion func­tion in Vim, and found this: a file that was last updat­ed three years ago, but that hasn’t been mean­ing­ful­ly updat­ed since 2006.

So how have Vim users been get­ting by?

As far as I can tell, Vim users who want JavaScript com­ple­tion have been using a plu­g­in called vim-bet­ter-javascript-com­ple­tion, which has a his­to­ry of exact­ly 0 pull requests and hasn’t been updat­ed since 2016. Not only are Vim users turn­ing to a plu­g­in for some­thing that should be native (I’ve seen this else­where with oth­er lan­guages, too), but that plu­g­in is effec­tive­ly inac­tive.

You might be think­ing, Well why not just sub­mit a PR to Vim’s native JavaScript com­ple­tion file?

Vim doesn’t accept PRs as com­mon­ly under­stood. For one, if you do sub­mit a PR, there is no team of peo­ple that might review it and merge it; there is only Bram Moole­naar, Vim’s Benev­o­lent Dic­ta­tor for Life. Sec­ond, this will not hap­pen via stan­dard VCS chan­nels; Bram will write his own patch based on your work, if and when he gets around to it.

Addi­tion­al­ly, in the case of syn­tax- and lan­guage-ori­ent­ed Vim com­po­nents, an inter­est­ed con­trib­u­tor is instruct­ed to con­tact the “main­tain­er,” typ­i­cal­ly indi­cat­ed in the head­er of a Vim file with an email address and/or URL. In the case of JavaScript com­ple­tion, that main­tain­er has a min­i­mal GitHub pres­ence; ide­al­ly, the file would be host­ed as a repos­i­to­ry on his Git host of choice, open for PRs, but this is not the case. I will have to email him to get any­thing done, on a core JavaScript com­po­nent with­in vanil­la Vim that hasn’t been updat­ed in at least 14 years.

(I mean absolute­ly no ill will against this main­tain­er, or Bram for that mat­ter. Con­tribut­ing to open source is often thank­less work done on evenings and week­ends, though I do believe the process­es around such a vital edi­tor could be improved.)

Ah!, you might now be think­ing, But what about Neovim?

Regret­tably Neovim uses the exact same ancient JavaScript com­ple­tion file from Vim. But sure­ly Neovim accepts PRs in a con­ven­tion­al way? I’m afraid not. After sub­mit­ting an extreme­ly mod­est PR to add some basic JavaScript meth­ods to Neovim, I was told once again to con­tact the main­tain­er, who will (in the­o­ry) accept or reject my sug­ges­tions, send those to Bram (not via PR, of course), who then might, might add them to Vim.


I’m cer­tain­ly no expert, but I would love to see four things hap­pen to Vim:

  1. Bram: Find two peo­ple you trust to review PRs, and merge them as PRs.
  2. Syn­tax and lan­guage file main­tain­ers: Put your files in a GitHub repo and open them to PRs.
  3. Neovim: More aggres­sive­ly ques­tion your depen­den­cies on upstream Vim for progress.
  4. Plu­g­in writ­ers: Con­sid­er sub­mit­ting your “improved lan­guage sup­port” plu­g­ins to core Vim, rather than fork­ing core func­tion­al­i­ty and per­pet­u­at­ing a depen­den­cy on plu­g­ins.

I some­times get defen­sive when peo­ple say that Vim users are crazy or have stock­holm syn­drome, but some­times I think they might be right.