My Vim values
There are many Vim users in the programming community - it's an editor that has been undergoing a resurgence in the last years due to its speed and with respect to modern IDEs. Vim is popular also with dynamic languages that rely less on the support for code generation and automated refactorings that most IDE sell. With no statistical validity whatsoever, I can also tell you Vim has been spreading like a virus in my office, feasting on colleagues that used to open Eclipse and Netbeans every day.
However, Vim has so many plugins and extensibility that you can almost turn it into an IDE if you want to. So here is my take on my Vim's values and what I accept into my .vimrc and plugins, along with what is out of place and in my opinion misses the point of using Vim in the first place.
Basically, my vision is inspired my the UNIX is my IDE motto, in that Vim should not reimplement or wrap external functionalities that are best provided by their own applications. Unix programs do one thing, and do it well: an editor shouldn't be capable of manipulating source control
There is mouse support in Vim. Nonetheless, it is out of place in an editor that tries to keep your hands on the home row for as much as possible. set mouse=all is definitely off limits
Also, no directional keys should be used: it is easy by googling to disable them and leave only hjkl plus the plethora of Vim movements (bewftBEWFT for starters) to navigate text while in normal mode.
I also avoid any remapping of basic functionality, such as movement between tabs or :set commands. When you pair with a colleague on another instance of Vim having memorized these hand movements, you're in for a surprise (unless you have a team-wide distribution like VimPeppers, but then you'll have to make pull requests on your shortcuts.)
One of the plugins that I use regularly is Ctrl+P; it has genuinely additional functionality with respect to :e by fuzzy matching file names, and it is standard enough that I can find it on my colleagues machines when working together.
The other plugin I find useful is snipMate, strangely an innovation brought about by another editor, Textmate. The responsiblity of being an editor has some connections with inserting boilerplate code; while I try to avoid the need for this kind of code at all, when I have to write too many namespace...class snippets snipMate comes handy.
More than the plugins I use, to express the vision of Vim as an editor and of Unix as the environment it's nice to make some examples of banned plugins:
- Git-related ones: I use the console or the !git command to access source control. Introducing a series of :Gs, :Ga commands is not dissimilar from installing an Eclipse Git plugin, and is potentially making me missing out on the whole set of Git commands and their switches which I could see from the command line.
- Ack: grep, ack, and many other filters are also available from the command line. I feel it's accidental complexity to display them in my editor (unless I want to edit their results or pass text to them, in which case :%! can include them in editor execution).
- NERDTree: using a terminal window to produce a file navigation tree. It's retro and maybe hipster but if you want a file navigation tree just open a window with the right UI controls instead of navigating in a 30-year graphics when you actually want to click around.
What I want
There is always someone purer than you (more pure). So here are my sins and how I am trying to overcome them.
- I want to switch to an US layout, to avoid Shift and Alt Gr combinations for basic characters such as some braces. I just have to find stickers and change my keyboard driver (or cover it all with black stickers like for a Das Keyboard).
- Deactivate page up and page down which I still resort to sometimes, to complete my transition to the home row. In laptops I usually do not jump to them as they are uncomfortably placed or need combinations, but in ordinary keyboards they're too easy to get to.
- Learn more about the execution of Unix commands from the editor - I just know a couple of tricks and they already cover so many cases, but why stop there?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)