[alwillis]

> I find that any IDE-type setup in vim causes vim to lose the most important thing, speed. If your movements slow down because of too many plugins, the experience is far worse than in a normal non-modal IDE.

Um… the word any is doing a lot of work in this sentence. I never had this problem on a 7 year-old iMac. I tried using VS Code on the same machine with just a few plugins on small projects and because it's an Electron app, I'd get frustrated and switch back to Neovim. VS Code has come a long way but it's no Neovim.

The beauty of new plugin managers like Lazy.nvim [1] is you could have 30 plugins configured but Lazy doesn't load all of them at once. In fact, it doesn't load any of ones you don't need and when they do load, it's asynchronous.

Plugins on Neovim run on separate threads from the editor itself, another reason we don't get those slowdowns you spoke of.

[zogrodea]

I can't comment on any implementation details, but at least with LunarVim (which I use for daily coding), a slowdown when interacting with LSP is very noticeable. Some others have attested to this on a GitHub issue.

I'm not doubting your experiences with the lack of a slowdown, but there is truth that others do experience it. That might be more of a problem with LunarVim itself rather than Vim, but how likely am I (as someone who would like to avoid what he calls "config hell") or other newcomers to avoid whatever pitfalls there are, if a distribution designed for ease of use by people who know better fall into them?

https://github.com/LunarVim/LunarVim/discussions/3359

[zogrodea]

After re-reading my comment, I think it was somewhat unfair. LunarVim is still the best and most comfortable code editing solution for me and the performance hit isn't that bad.

The point I made about config hell might also be a bit out of place in this subthread since ease of use wasn't brought up explicitly in the comment chain I'm replying to (although distributions aiming for ease of use were mentioned).