When editing a file in Vim, you can choose which is its file type. Knowing the file type, Vim can load the correct syntax highlighting, and in some cases certain functionalities of plugins may be activated and used.
To have syntax highlighting, you need this setting:
After this, Vim will set the file type for any opened file automatically. So if you open a Python file, Vim will set the type to
The user can always change the current file type to anything else. A common case is setting the file type to
plaintext, which causes language specific syntax highlighting to go away but doesn’t shutdown the highlighting for other opened files:
File Extension Conflicts
Sometimes, a file may be opened in Vim, but the file type is interpreted incorrectly. In this case we have to set the correct type by hand.
Take the example of opening a Prolog file. The file extension of Prolog is
.pl. However, the extension for a Perl file is also
.pl. So when a
.pl file is open, regardless of it being a Prolog or Perl program, Vim assumes the Perl file type.
Vim assumes Perl simply because it is much more famous and highly used then Prolog. But for me personally, Prolog is more important. This is because I’ve made some development in Prolog in the passed, and have never actually used Perl for anything.
So every time I want to edit a Prolog file I would have to write:
But this would be extremely cumbersome to do. So I add an automatic command that executes every time a buffer which name ends in
.pl is created or read. That line looks like this:
autocmd BufNewFile,BufRead *.pl :set ft=prolog
The command is
autocmd, which is executed on the events
BufRead, for buffers which end in
.pl. The automatic command which is executed is exactly what we saw before:
Like this, Vim assumes file type Prolog for any
.pl file which I open.
File Extensions in my
At the time of writing, this section of my
vimrc looks like this:
" Make .pl files load like Prolog and not like Perl autocmd BufNewFile,BufRead *.pl :set ft=prolog " Make .tex files load like tex files. autocmd BufNewFile,BufRead *.tex :set ft=tex " Make .md files load like Markdown files. autocmd BufNewFile,BufRead *.md :set ft=markdown " Make .rl file load as Go autocmd BufNewFile,BufRead *.rl :set ft=go " Make Emakefile files load like Erlang files. autocmd BufNewFile,BufRead Emakefile :set ft=erlang " Make ejs file load as HTML autocmd BufNewFile,BufRead *.ejs :set ft=html " Make .docker files load as Dockefile autocmd BufNewFile,BufRead Dockerfile.* :set ft=dockerfile autocmd BufNewFile,BufRead *.docker :set ft=dockerfile
Without these rules,
.tex files would open as
plaintext instead of LaTeX, and
.md would also open as plain text instead of Markdown, although in recent versions of vim, they already open as Markdown out of the box.
The other rules I have are for specific library file types. We have the
.rl files which are from a Go library called Ragel. This library is used to make Flex typed Lexers (to build parsers or compilers). I never actually used this library in a big project, but I’ve made experiments with it. Despite having a specific file name, the code contained in a Ragel file is Go, so my Vim will open these files as Go files.
I’ve made some experiments with Erlang, and I like the language quite a lot. The
Emakefile is a specific type of
Makefile to compile an Erlang program to the Beam Virtual Machine. Like Ragel, the code in these files is simply Erlang, hence the rule.
I want to see the
ejs files, but since the templating part was so simple, it was also not needed.
Finally, the last part of this section is about Docker files. I’ve seen and worked on many projects that used files with names starting with
Dockerfile. and others ending with
.docker. I naturally have rules to make these files open with the file type
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