What I like about Vim is that it has a limited set of features out of the box. As a result, I feel that I have a strong understanding and command of Vim. If I w

What I like about Vim is that it has a limited set of features out of the box. As a result, I feel that I have a strong understanding and command of Vim. If I want an additional feature I can either add it myself or look for an available plugin. With plugins I usually go through an adoption period where I try to determine if the benefits of the added features outweighs the loss of total understanding of my setup or any degradation in performance. In other words, I enjoy that Vim is an onion with few layers. In contrast, modern GUI IDEs are more feature rich out of the box, but at the cost of tool complexity. Simple workflows are generally easy to get working, but adapting the tool to a complex workflow can have me clicking obscure options on the Nth option page without an understanding of what I've just done to solve the issue. As someone who works on a variety of codebases, tinkering around with setups for each project can (a) become a serious time sink and (b) can increasingly make me feel like I don't understand the tool if each setup seems to be relying on disjoint sets of new-to-me configuration options. Additionally, I personally feel that "magic" utilities can rob me of my understanding of languages and codebases. It helps me rest easy at night knowing that I can create a codebase from scratch without needing to rely on "Create new C++ class ..." and automatic refactoring features provided by an IDE. Regardless of my preference for Vim, I have found that a distributable configuration for a modern feature-rich IDE can be an invaluable asset for open source projects. Being able to open an IDE, load a configuration, and press the build button can remove significant barriers for contributing to projects where your understanding of the codebase and build system are nonexistent.