3 ms·

I understand that your company butted heads with the Vim maintainers last year (as discussed elsewhere in this comment thread), and that an asynchronous plugin

I understand that your company butted heads with the Vim maintainers last year (as discussed elsewhere in this comment thread), and that an asynchronous plugin architecture would be super-helpful to your company's integration needs. However, if you are announcing with a straight face that Vim slows you down because of synchronous regex scans, then that is flatly ridiculous. Are you editing terabyte-sized source files? Because if so, then perhaps some refactoring is in order (get the PyCharm guy to do it)! My mind is boggled by the number of plugins one would need to install in any text editor for the difference between synchronous and asynchronous execution to even be perceptible on a contemporary laptop with a typical file. I mean, if you are happy with your text editor of choice, then godspeed and enjoy ("editor wars" are always a bit tongue-in-cheek). However, if you're adding a slew of IDE-like plugins to Vim (especially a pig like NERDtree), then beyond a certain point it makes more sense to just install the JetBrains product relevant to your language, and use whatever keybindings you like from within that. The way you guys all keep plugging NeoVim (which doesn't even have an alpha release yet) definitely smells fishy, a transparent axe to grind. The Vim guys didn't want your patch. Sorry.

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.

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.