Archive | December 2018

Stuff in my vimrc: 02 File Extensions

In my previous post I wrote about the general settings in my vimrc. I continue to explore my file, hosted here. In this post, I’ll be talking about File Extensions.

File Extensions

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:

syntax enable

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 python, a JavaScript file will be javascript, and so on.

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:

set ft=plaintext

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:

set ft=prolog

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 BufNewFile or BufRead, for buffers which end in .pl. The automatic command which is executed is exactly what we saw before:

set ft=prolog

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.

In a personal project I’ve made two years ago, I’ve used ejs, Embedded JavaScript Templating. This is a Node.js templating library which I used to generate static HTML pages for a simple web application. The library is very similar to other templating libraries, such as Django Templates, Go Temples, Java Spring Templates, and others.

I want to see the ejs files as HTML, despite the fact that some of its code (the actual template code) is JavaScript. When I worked with this, there was no way of having syntax highlighting for HTML and JavaScript at the same time in an 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 Dockerfile.

<- Prev – 01 General Options | Next – 03 Folds and why I don’t use them ->

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.

My vimrc file is hosted in here.

Outlook

A 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:

  • Plugins
  • General Options
  • File Extensions
  • Folds
  • Language
  • 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.

General Options

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.

Lines

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:

set cursorline
set number

Tab Completion

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 :e login.py.

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:

set wildmode=longest,list,full
set wildmenu

Splits

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:

set splitbelow
set splitright

Backup Copy

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:

set backupcopy=yes

Indenting

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
set tabstop=4
set expandtab
set backspace=indent,eol,start

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:

set background=light
colorscheme solarized

So the theme is solarized, and the variant is light, as opposed to dark.

Next – 01 File Extensions ->