Stuff in my vimrc: 01 General Options
Vim has been one of the most important tools in my toolbox. Since 2013, it has been the editor I’ve used for everything. From developing projects in Python, Node, Go, C, to writing my Master’s Degree Thesis, and this Blog Post.
Customization is quite common when using Vim. We want different key binds and features, and it is through these key binds and features that we adapt and develop our own Workflow.
Vim Customization comes mostly by writing a
vimrc file. In this series of blog post, I will talk about stuff I have in my
vimrc file is hosted in here.
vimrc file is usually developed overtime by the person who uses it. People sometimes take ideas from other people’s
vimrc, but one should never copy a whole file.
My file is not particularly big. I have the following structure to it:
- General Options
- File Extensions
- Highlight Unwanted Spaces
- Maps and Keybinds
- Plugin Specific Options
I’ll make a post for each of these points or for specific details within the points. I’ll start by the General Options section of the file. I’ll talk about the Plugins later.
The General Options have the most basic kind of settings. When I’m using an instance of Vim which doesn’t have any configuration, for example in a server, I usually some of this setting directly on the command line.
I’ll be talking about my choice of options in no particular order.
I like to have a background highlight in the line where the cursor is located. This line is present in every windows which is showing in a particular tab, so if I have the screen split to display multiple files, of many locations in the same file, the cursor line will still be highlighted, even if the cursor is not currently on that window.
Off course the lines are also numbered. I use the regular numbering as opposed to the relative numbering, since I could never get used to the regular numbering.
For these things, I use the following options:
Not to be confused with semantic completion, this is about how the tab completion for the vim command line works. I have a lot to say about semantic completion, but that is not in the scope of this particular blog post.
Out of the box, the completion of the vim command line works like this. Suppose you want to open a file called
logging.py. So you write
:e log and now you would press tab to autocomplete to
:e logging.py. But instead, you get
This is because vim will pick the first alphabetical option from a pool of options and present it for autocompletion. If you press tab again, you would get the next option, and tab again, you get the next, and so on.
I prefer to see the list of options first, and then start tabbing over the options until the one I want. Inside the editor, be that to pick files or commands, this just seems to make more sense to me. So I use these options:
When you split the current window either horizontally or vertically to see different sections of a file, or another file, that is called… well, a split.
You can issue a command to split the current window and open a file in the split at the same time. The thing is, by default, vim splits the window and the new file will be on top or on the left, depending if the split if horizontal or vertical respectfully.
I prefer the opposite behavior. So, I can issue the command
split newfile, and the new file will open in the split on the bottom. Same with
vsplit newfile which opens the file in the split to the right.
I have these settings for this:
In many projects, you have a workflow which works like this: The project is running, you change a file, something auto compiles your changed files, the project restarts or reloads, and you see the results of your changes right away. You see this, for example in Django projects, where the runserver reloads and restarts the server upon a file change, or in an Angular project, where the files are compiled, and the browser refreshes.
Sometimes, Vim doesn’t write the changes to disk right away, or only the
.swp is written. When this happens, the autoload features simply don’t work, because no file change could be detected.
To avoid this, I have this option which guaranties that the files are always written to disk when I issue the save command:
I use spaces. Specifically, an indent block for me is four spaces. Unless a project requires tabs or a different indent block, I keep these settings.
I change the tab key to write an indent block instead of a tab character. Some file types, like Makefile, will ignore this behaviour since Makefiles actually need a tab character.
I also make it so a backspace over indent sections of the line deletes the whole block and not the individual spaces that make that block up. Lastly, in many languages, when I press return after an opened braked or after a colon, a new indent block is placed.
set shiftwidth=4 softtabstop=4
Colors and Themes
I like light themes as opposed to dark themes. I also like the Solarized theme. I’ve been using Solarized Light for many years now, and don’t plan on changing it.
I use a Vim plugin to have the Solarized theme available and I set it as my theme with these commands:
So the theme is
solarized, and the variant is
light, as opposed to