[capableweb]

> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own.

> Couldn't they not convince Bram Moolenaar of proposed changes

I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason.

That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript.

But that's how I remember it being started at least, but I could remember it wrong.

[aidos]

Correct. HN threads from the time:

https://news.ycombinator.com/item?id=7057051

https://news.ycombinator.com/item?id=7278214

[dvogel]

This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2...

My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):

    You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*

The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:

    Bram,
    I happy to see there is still some hope for this patch getting merged.

Then shortly afterward the other author gave Bram an ultimatum:

    Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
    
    If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.

Considering where the patch started, iterative feedback seems appropriate.

Bram replied (in part):

    It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.

The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.

[mkh]

I caution anyone reading this to not take this summary at face value. If you're interested, you should read the linked threads for yourself. I'd say you can leave out that someone followed up on some technical detail three years later, but you be the judge.

FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.

That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.

[mayama]

> The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.

So, who forked neovim and what does this timers patch have to do with forking if the patch authors weren't the ones forking neovim.

[dvogel]

The founder of neovim did briefly attempt to participate in the vim dev process. This was a few months later. The most relevant thread is here:

https://groups.google.com/g/vim_dev/c/65jjGqS1_VQ/m/fFiFrrIB...

He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:

https://news.ycombinator.com/item?id=7279358

In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.

[mempko]

Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.

[TotempaaltJ]

As above[0], these are different people than the author's of neovim

[0]https://news.ycombinator.com/item?id=31942444

[mempko]

Weird, so people who give justification for neovim and use that thread are wrong. Thanks.

Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?