I should not blindly trust packages auto generation

I use Emacs on a few different systems but mostly on a desktop at home, a Dell ultrabook on the go and another desktop at work. All systems have the same Debian stable version installed so I thought it should have been painless to maintain a uniform environment on the three installations.

That was put in question when I noticed the Emacs' mode line on the desktop at work was different than the laptop; diminish is an Emacs module that reduces the amount of space taken on the mode line by the active minor modes and it wasn't working on the desktop.

I was baffled when the different behavior of the diminish package persisted even after synchronizing the configurations on the two systems and reinstalling the package from the MELPA repository. I should have taken the clue instead of trying to find the reason of the inconsistency on the configuration files.

In fact, a quick inspection of the freshly installed package from MELPA revealed that the diminish-autoloads.el file was missing the provide statement:

(provide 'diminish-autoloads)

Even if both systems had Emacs 25.0.50 installed, the diminish package on the laptop was downloaded long time ago using Emacs stable, so I suppose this solves the mystery. Until now I stored only my Emacs configuration files in a Git repository and relied to a script to download the eventually missing package during Emacs' start-up, but I'm reconsidering that choice and thinking to put everything back under Git.

I guess I've learned that I should not blindly trust Emacs automatic generation of autoload files.

Now say that last one faster.

Virtualenvwrapper and Python 3

This is mostly a note for my future self as for sure in a couple of months I'll forget about it.

According to the documentation, current version of virtualenvwrapper is tested to work with Python 3.4, but it's not very clear on how you need to configure it, at least after a cursory glance. Well, it follows the VIRTUALENVWRAPPER_PYTHON environment variable if defined, so after declaring the path to a Python 3 interpreter, it should start working (the path depends on the OS/environment, so the following should be modified accordingly by the reader):

export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3

Another thing to note is that the virtualenvwrapper.sh script seems not to be re-entrant, at least with my configuration. My quick workaround is to evaluate it only once:

if [[ -z "$VIRTUALENVWRAPPER_HOOK_DIR" && \
      -e /usr/local/bin/virtualenvwrapper_lazy.sh ]]; then
   source /usr/local/bin/virtualenvwrapper_lazy.sh
fi

I should probably check if someone has filed a bug report.

It's alive!

It was a long time coming, I had a server buried deep in a data center somewhere in central Europe, sitting idle for months as I was looking for an original name for the domain, not an easy task nowaday.

Perusing the TLD lists looking for clever combinations, inspiration struck, so with Gene Wilder immortal words I can annunce: "Alive! It's alive!".

"Alive! It's alive!"

Well, to be honest in my head the domain name sounded better, but it's somewhat funny, especially if you happen to know me. So to make a long story short, last weekend I registered the domain, configured the web server and leashed it to the world.

Better late than never.