The "effect" that you described was being unable to work at a normal speed, because you browse directories faster than NERDtree can display them. Because you can't start a text search in a background thread, and work with other files while that's running. Etc.
You know, about once or twice per day I have to do a text search through a 750,000-line codebase. IntelliJ blocks also, but it completes in 3 to 4 seconds... and Vim searches a hell of lot faster than IntelliJ. In two decades of working with vi/Vim, I've only experienced UI sluggishness when working with log files that were each hundreds of megs in size.
So to be clear, when I suggested that you might use too many plugins, that was sarcasm. To be even more clear, I was flatly calling you a liar about your original premise.
Synchronous vs. asynchronous plugin execution is not an "architectural shortcoming". It's an "architectural decision". An architectural shortcoming is something that two separate submitters can't each resolve with a single patch. Right or wrong, the Vim maintainers were given the option... and apparently made the conscious decision that the benefits of asynchronous plugin execution aren't worth the risk of plugin authors doing dumb things with it.
I do wish that they had been more forthcoming with your company in how they did (or didn't) convey that decision, but ultimately it's their call. Creating or supporting a fork is likewise your call. But at least be honest about the agenda. You guys take an active interest in criticizing Vim, and promoting NeoVim, because the Vim maintainers rejected a patch that would help your startup company integrate with them. Not because the syntax highlighter can't keep up with your Warp 9 typing.
You know, about once or twice per day I have to do a text search through a 750,000-line codebase. IntelliJ blocks also, but it completes in 3 to 4 seconds... and Vim searches a hell of lot faster than IntelliJ. In two decades of working with vi/Vim, I've only experienced UI sluggishness when working with log files that were each hundreds of megs in size.
So to be clear, when I suggested that you might use too many plugins, that was sarcasm. To be even more clear, I was flatly calling you a liar about your original premise.
Synchronous vs. asynchronous plugin execution is not an "architectural shortcoming". It's an "architectural decision". An architectural shortcoming is something that two separate submitters can't each resolve with a single patch. Right or wrong, the Vim maintainers were given the option... and apparently made the conscious decision that the benefits of asynchronous plugin execution aren't worth the risk of plugin authors doing dumb things with it.
I do wish that they had been more forthcoming with your company in how they did (or didn't) convey that decision, but ultimately it's their call. Creating or supporting a fork is likewise your call. But at least be honest about the agenda. You guys take an active interest in criticizing Vim, and promoting NeoVim, because the Vim maintainers rejected a patch that would help your startup company integrate with them. Not because the syntax highlighter can't keep up with your Warp 9 typing.