No, he didn’t. He didn’t cave. He was working on async, for a long time, with the goal of producing an async feature that actually fit in with the rest of Vim’s API and the rest of VimL, which he did.

Where did you get this narrative from? The original post provides links to the discussions of Thiago’s and Geoff’s respective attempts at this. I don’t see what you described at all.

Can you link to any discussion about Bram working on async for a long time before?

NeoVim is incompatible with vim, not the other way around.

Huh? Vim didn’t have this feature at all, a bunch of plugins adopted Neovim’s design, Vim broke compatibility with those plugins by releasing an incompatible implementation of the same thing, forcing plugin maintainers to build separate compatibility pipelines for Vim. Some examples of this is fatih’s vim-go (some related tweets: https://twitter.com/fatih/status/793414447113048064) and Shougo’s plugins.

I get the whole “Vim was here first!” thing this is about the plugin ecosystem.

Async in vim fits in with the rest of vim much better than NeoVim’s async API would have fit in with vim.

How’s that?

Here is the discussion of the patch to add vim async from Bram, where he is rudely dismissive of Thiago’s plea for a compatible design (no technical reasons given): https://groups.google.com/forum/#!topic/vim_dev/_SbMTGshzVc/discussion

The whole point of NeoVim is to remove features that they don’t personally use because they don’t think they’re important. There are a lot of Vim features not in NeoVim.

What are some examples of important features or features you care about that have been removed from Neovim?

The whole point of Neovim (according to the landing page itself: https://neovim.io/) is to migrate to modern tooling and features. The goal is to remain backwards-compatible with original vim.

Vim is stable, reliable and backwards-compatible. I don’t fear that in the next release, a niche feature I use will be removed because ‘who uses that feature lolz?’, like I would with neovim.

Do you actually believe this or are you being sarcastic to make a point? I honestly can’t relate to this.

The vim vs. neovim debate is often framed a bit in the style of Bram vs. Thiago, and the accusation against Thiago is typically that he was too impatient or should not have forked vim in the first place when Bram did not merge Thiago’s patches. I have the feeling that your argumentation falls into similar lines and I don’lt like to view this exclusively as Bram vs. Thiago, because I both value Bram’s and Thiago’s contributions to the open source domain, and I think so far vim has ultimatetively profitted from the forking.

I think there are two essential freedoms in open source,

• the freedom of an open source maintainer not to accept / merge contribution,
• in the very essence of open source, that users have the right to fork, when they feel that the maintainers are not accepting their contributions (preferably they try to make a contribution to the source project first).

Both of this happend when neovim was forked. There is no “offender” in any way. Thus, all questions on API compatibility following the split cannot be lead from the perspective of a renegade fork (nvim) and an authorative true editor (vim).

You can host a 1x1 pixel on Amazon S3 and enable logging for the associated bucket. Add a query string to identify the current page. A simple transformation on the logs (to remove original URI, keeping only the one in query string) and you should be able to use GoAccess.