3 ms·

I point out an architectural shortcoming, explain how it affects me, and you say the real problem is that I have too many plugins, the files I edit are too big,

by ggreer 12y ago

I point out an architectural shortcoming, explain how it affects me, and you say the real problem is that I have too many plugins, the files I edit are too big, or my computer is too slow? Whose mind is boggled now? The way you guys all keep plugging NeoVim (which doesn't even have an alpha release yet) definitely smells fishy. The Vim guys didn't want your patch. Sorry. There's nothing fishy about our support for NeoVim. We don't know the authors (though I, personally, did throw some money at the Bountysource). There are a few reasons why we like them: 1. They share our pain. Thiago de Arruda (main author of NeoVim) tried to add a similar patch to Vim. Like us, he spent months trying to work with the Vim community before being rejected.[1] 2. We like NeoVim's architecture. If we had infinite time, we'd be writing a very similar editor. 3. NeoVim makes our product better for Vim users. They get the UI they love, but without a broken leaderkey or other annoyances. While the readme says it's alpha-quality, it works fine. It can be used with current Vim plugins and performs better than Vim. 1. https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIBwNAJ https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIB...

StevePerkins 12y ago
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.

by ggreer 12y ago

StevePerkins 12y ago

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.