> Rather than invest time in working through the problem
I don't think this is a fair characterization. We've made significant investments in both Neovim and Vim, and carefully considered the trade-offs.
> Guts of it is that Neovim didn't play nicely with their OCaml build and Vim did
This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously.
There was a significant amount of incidental complexity in the architecture of our V1 to fit that asynchronous model - we wanted to avoid that for V2, and we switched to Vim because it fit that model.
I don't think this is a fair characterization. We've made significant investments in both Neovim and Vim, and carefully considered the trade-offs.
> Guts of it is that Neovim didn't play nicely with their OCaml build and Vim did
This was a smaller consideration - but more fundamentally, the model Neovim uses for input - queuing it on an event loop and handling it asynchronously - is at odds with what we required - to be able to process the input -> handle updates synchronously.
There was a significant amount of incidental complexity in the architecture of our V1 to fit that asynchronous model - we wanted to avoid that for V2, and we switched to Vim because it fit that model.