But then I found about IntelliJ IDEA, and quickly forgot about all the pains I had experienced with Eclipse. Now that was a wonderful, intelligent, productive environment in which to program. So I dismissed my grandeur dreams of a DIY IDE.

However, I didn’t stop using Vim! I have been using it for everything else. Mostly Python, but a bit of C too. I like it specially when I’m on my laptop. Firstly, because I can’t seem to get to speed with the button-less touchpad in the new Macbooks, so I’d rather avoid using the touchpad. Secondly, because the battery lasts like forever when using Vim only and not a full-blown IDE such as IntelliJ.

As an example, I wrote the patch for pommed on newer Macbooks on the plane from London to Valencia, which takes two hours and a bit. When I arrived, I still spent a day or two testing and dabbling with the pommed code until I had to plug-in the charger again.

I still have much to learn about Vim, but one of the things I wanted to solve was that I had to manually sync my Vim settings between my laptop and my desktop. I noticed some people were publishing their .vim directories in github, and I thought that it was a terrific idea: that way I could keep everything in the famous cloud but still have a local backup (with history) if the cloud was blown away!

And after studying other people’s github .vim repositories, here’s my imaginatively named repository: dotvim.

How it works

Vim stores each user’s settings in a .vim directory, in the user’s home directory. In my case, that is /home/sole/.vim, but that depends on each operating system and distribution. It might be /Users/sole in Mac, if I remember correctly.

So as everything is in a directory, it’s an ideal situation for a git repository. We can place all our favourite plug-ins, color schemes and etc inside that directory and they will just be a git clone away when needed.

The problem is that the file Vim reads when starting up, and where all the personal settings are stored and scripts are launched for a user is not inside .vim, but at the same level than .vim: on the user’s home directory. So in my case, its full path is /home/sole/.vimrc

How do we version a single file with git? Well, I found the answer in Tsung-Hsiang Chang‘s .vim repository: you don’t. Instead, you place it inside the versioned .vim directory, and make a symlink to it. That way it’s kept in the repository along with the rest of vim-thingies:

Doing all this manually is a hassle. It really demands automation! And someone had thought of that already: Vincent Driessen devised both an .sh script for cloning his .vim dir and making the symlinks, and also a nifty one-line which does all the work if you’re in a brand new setup with no .vim or .vimrc on it:

I liked that idea, but I splitted it into install.sh, which sets up symlinks and updates the git submodules, and superfastinstall.sh which clones the git repository and then calls install.sh in order to complete the installation. This was more modular (and easier to test).

And that’s roughly how the setup is done.

But… gVim?

One of the aspects that annoys me of most editors is the colours. It looks like people either don’t care or their tastes are diametrically opposed to mine, and Vim was no exception. I tried all the color schemes but I liked none. So I decided to finally learn how to make my own color scheme… only to find that it’s a bit tricky!

Due to Vim’s longevity, it has to cover a lot of use cases: running on an ancient terminal, on a colour terminal, on a proper colour terminal, and on “the gui”. “The gui” are gVim, MacVim and all the other versions of Vim surrounded by nice menus for opening and closing files and copying and pasting. The ancient terminals–well, I haven’t had the opportunity of experimenting with those, so I’ll just assume it’s something clunky and left to collect dust in a storage basement, or it’s what banks and flight companies use to keep track of our movements. So that leaves us mere mortals with the colour terminals, and you might be wondering what’s the distinction between them and the “proper colour” terminals.

But wait–we don’t really use colour terminals. We use terminal emulators! Physical colour terminals are apparently limited by hardware to a fixed set of colours associated with numeric codes: a palette. Thus, the emulators follow this behaviour as well. So if you ask an emulator to show this or that colour, it will look up the corresponding colour in the palette. This means that you can define different “profiles” which modify the palette, amongst other aspects, and the same program can look different depending on the profile you’re using.

With this scenario set, you can safely anticipate that building a color scheme based on a palette that can be arbitrarily changed is going to be a mess, or at least difficult.

Vim works around this by allowing you to specify different colour values depending of the context Vim is running on. So you can say: I want the “Normal” text to be “Black” on a simple terminal and on a colour terminal, and slightly off dark grey in a gui, and I want the background to be a “Light Grey”. That, in Vim, is done this way:

If I tell you that ctermfg means colour terminal foreground, I think you can safely deduct the rest.

And generally, Black is black in the terminal profiles I’ve tested, but sometimes I specified other colours and got either something completely different, or just no change, like there were some hardware incompatibilities that the emulator was also following to the letter, and maybe it couldn’t show bold yellow over grey but could instead show bold magenta over grey.

I finally found that this was happening because apparently the GNOME Terminal that ships with Ubuntu is not capable of showing more than 15 colours. You’ve got to do “stuff” to get it to show more colours. The “stuff” was recompiling, according to some sources, or changing some values, according to other sources, or both, according to yet other sources.

At the end I just decided I’d focus on making a colour scheme that was “OK” when running on the default Ubuntu+GNOME terminal and “nice” when running on gVim (which does obey my colour indications and also allows to use RGB values!). It’s the colour scheme that I’m using on my .vimrc, sole.vim, and that is still in its infancy since it’s missing definitions for many values O:-)

Unfortunately gVim had an annoying quirk: I could paste something from the GNOME clipboard with Shift+Control+V when running Vim on a terminal, but that didn’t work on gVim. Instead, I had to use something as intuitive as “+gP. But guess what? I found a way to remap Control+C and Control+V to perform copy and paste:

And while I was at that, I thought I would change the font face too. I settled on Inconsolata, as recommended by mrdoob. I also changed the status bar to something a bit more spiced (thanks to Tsung-Hsiang’s vimrc again), followed a tutorial to make Vim more suited to Python programming, and made sure that NERDTree was included as a git submodule, so that it would always be available whenever I installed my .vim in a computer.

So this is how gVim looks like currently (after removing the toolbar!):

And as I wanted the same settings and scripts available both when using vim or gvim, I symlinked both .vimrc and .gvimrc (which is what gVim uses) to the same file. I’m not sure if this is the best practice but it’ll stay this way for now. Update: it’s not the best practice, as Andy Todd lets me know in the comment below! gVim reads first .vimrc and then reads .gvimrc, so I’ve created a .gvimrc file containing gui stuff only, and updated the install script that creates the symlinks too. It’s updated in my repo already :D

Finally, one for the curious: this is how I calculated how many days had elapsed since I started using Vim (taking my first Vim post as time reference).

You wouldn’t expect me to add the days up manually, would you!? ;)

I think it happened for the first time almost 10 years ago. I had to implement a little shell in C for a university assignment and brave me hadn’t a better idea than printing parts of the code from bash and examining it to get an idea of how the real stuff worked. It was all fine and dandy when reading the code at a train (apart from the odd looks that I got from people sitting near me, of course), but it proved to be a very bad idea to keep reading right before going to sleep. That night was the prelude of a long series of bad nights. I spent the whole night dreaming about pointers, structures, functions, loops, assignments, switch statements, case’s, mallocs… you get the point. When I woke up, my brain was totally wasted. It was just like if I hadn’t slept at all.

I thought that had only been a single event and wouldn’t happen again, but boy, wasn’t I wrong! It didn’t happen again, though, until I began to work in web development, and the main cause this time was the Horror. Of course, I’m referring to Internet Explorer Exploder. I have lost count of the number of nights I spent suffering horrible nightmares where things work properly in Firefox and Opera and blah but aren’t properly aligned in IE, or do not show where they should… Anyone who has had to develop for IE will for sure know what I mean.

The easiest way of avoiding these nightmares (for me) is to consciously focus on something completely unrelated before going to sleep. For example, to read something non-technical, like a fiction book where the action preferably happens in a time and place where the most advanced piece of technology is a ball pen.

But over time, there are days where I can’t but get super excited about something code wise, and continue coding right until my eyelids feel so heavy I can hardly keep my eyes open. Those are the nights I go to sleep scared in advance, because I know my brain is totally obsessed with the piece of code I’m working with, and as Bette Davis would say, … it’s going to be a bumpy night! :D

And you? Do you have real coding nightmares? And if you have, how do you avoid them?

My hosting compresses access_logs which reach a certain size, so when I downloaded the access logs files I get a bunch of .gz files which I’m not going to manually uncompress… So I went to the terminal and once in the folder where the log files are, I type

find . -name “*.gz” -exec gunzip {} \;

Now I have lots of files like access_log.20060929, access_log.20060930, etc. For searching let’s say a referrer called example.com which I see in GA, I do:

cat * | grep example.com

and that will return you the apache log lines where the term appears.

For example:

81.39.91.97 – - [26/Sep/2006:11:27:47 +0000] “GET /index.php HTTP/1.1″ 200 9562 “http://example.com/viewtopic.php?t=747″ “Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7″

It’s a bit of brute force approach as it’s searching in all the files (now that I realize it’s even searching in the compressed files since I didn’t remove they yet, haha!). But it’s very fast even though!

With a bit more of love this could be a rudimentary stats script but I’m not that much into shell scripting (and I’m trying to force myself into really learning regular expressions to do that stats script with ruby instead).
Oh and I forgot to say this works for any decent shell – linux, mac… I think I also could do it with a windows box with unxutils installed (so that you get the funky stuff like grep, find, cat, etc).