teranex weblog

I finally took the time to make my 'drupaldev'-repository available.

First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as devel, diff, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the modules folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.

For Drupal7, I usually just create a symlink, named devmodules7, in sites/all/modules. Like this:

1
2

# from the drupal root of the project
ln -s ~/drupaldev/devmodules7 sites/all/modules/

The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on drush make to manage the modules. Instead of copying all the modules in my repo, I only keep a make-file for each Drupal version (currently 6 & 7). This makes it really easy to update all the modules, as I can simply run the makefile again. To make this even easier I have added a build script which will run all the drush make-files with the correct arguments:

1

./build

While playing with XFCE (more on that later) I was searching for a tool equal to gnome-open. Gnome-open can be used under Gnome to open files etc in the preferred application. While Googling I found not one, but two tools in various blogposts and forum messages: xdg-open and exo-open. I tried both, and both did the trick.
So that left me wondering: what's the difference after the two? Googling didn't really give a useful answer.
Yesterday I found the answer, by accident: exo-open is the tool from XFCE to open files etc in your preferred application, similar to gnome-open, under Gnome, and kde-open under KDE. xdg-open is a shell-script which works independent from the desktop-environment. It will inspect your environment and if it can detect that you are running Gnome, KDE, XFCE or LXDE it will use the correct tool from your Desktop Environment (such as exo-open under XFCE). If it can't detect your environment it will try to open the file itself. So basically, if you know which Desktop Environment you are running, you can use the tools which comes with your DE. If you're uncertain, or you are writing a script which should work across different Desktop Environments, use xdg-open. Or simply always use xdg-open.

A few days ago I took the time to finally rewrite the code for my Bash prompt. I had been using the prompt for nearly two years, but the code was fugly and had some problems. Now it runs without problems and is nicer so I can finally share it with the world. You can find the 'trexprompt' in my dotfiles repository on github. It also has a project page on this site with installation and configuration details. The prompt has the following features:

• Shows the current path, trimmed in the middle for very long paths.
• Shows the current load and time when last command finished on very wide terminals, right aligned.
• When inside a Git repository, shows the current branch and state
• Shows the exit code of the previous command when non-zero
• Configurable colors (left and right)
• When no colors are configured, colors will be calculated based on the hostname. So every host will automatically display other colors.

And a screenshot:

Audex is a really nice (KDE) application to rip Audio CDs. It can lookup the CD information (so most of the time you don't have to type all the tracktitles yourself), it also tries to fetch the correct cover (and succeeds most of the time) and has very flexible configuration settings. Sadly, the version in the Ubuntu (currently 0.72b1) repositories has a few problems when you want to encode your songs in Ogg Vorbis. Here is an overview of the problems I had and how I hacked my way around them (without recompiling Audex), so I can use Audex to rip my CDs to Ogg Vorbis.

The most important problem is that Audex simply doesn't detect the Ogg Vorbis encoder. As documented in this Debian bug report Audex passes an incorrect parameter to oggenc to detect the version. While it should pass -V (uppercase V) it passes -v (lowercase v). To 'fix' (read: hack) this I took the following steps:

• First check that your have the Ogg Vorbis encoder (oggenc) installed. In Ubuntu you can install it from the repositories by installing the 'vorbis-tools' package:
  

  1	sudo apt-get install vorbis-tools

• Now you should have the Vorbis encoder in /usr/bin/oggenc. But Audex won't detect it because it will call it with an incorrect paramter. So to fix this I first renamed oggenc to 'oggenc_real':
  

  1	sudo mv /usr/bin/oggenc /usr/bin/oggenc_real

Ever since I started using Vim as my preferred text editor I have been keeping my configuration under source control. At first I kept my config for all the various applications + some useful scripts in one Git repository. But after I had given a (very) short presentation at work, I started to think about splitting of my vim-configuration into a separate repository. I have already learned a lot of useful tricks and settings about vim by studying other peoples vimrc-files, so I feel like it's only fair to also put mine out in the wild.

So first I did a little Git magic to split of my vim subdirectory into a separate Git repository, without losing any of the history. The answer on how to do this can be found on StackOverflow: Detach subdirectory into separate Git repository.

Then I created a repository on Github and pushed my entire vim configuration. Feel free to explore it and use pieces from it. (Or use it in it's entirety, but I don't think that would really be useful)

Some 'cool' features I use in my vimrc:

Pathogen

A few weeks ago I started using the Pathogen-script for vim. This script makes it possible to keep every vim-plugin in it's own directory. To use Pathogen you need to call at least one of it's functions so it can do it's job. I choose to keep this initialization in a separate file from my vimrc-file. That is why my vimrc starts with the following line:

A few days ago I wanted to know how easy it is to redefine a function in Javascript which is already defined. I know that doing something similar in Ruby is rather easy and I had the feeling that it would be possible in Javascript as well.

After some googling and testing I came up with the following test document (which is perfectly valid HTML5 btw!):

1
2
3
4
56
7
8
9
1011
12
13
14
1516

<!DOCTYPE html>
<title>foo</title>
<script type="text/javascript">
  function foobar() {
    window.alert('hello');  }
 
  oldfoobar = foobar;
 
  foobar = function() {    window.alert('hello overwritten');
    oldfoobar();
  }
 
  foobar();</script>

I'm not sure if this is the 'javascript-way' of doing things, but it works. First I defined the function foobar(), which simply shows a 'hello' alertbox. Then I redefined that same method to first display another alert, and then call the original function, which will still show the 'hello' alertbox.

While the example is not very useful, this technique could be useful to redefine a method of some framework to attach custom logic (such as logging) without having to modify the framework itself.

Today I'm happy to launch the new version of my weblog. (Oh and also the rest of the website, although some content still needs to be updated.) This is version 3 of the weblog, not counting my very first weblog at blogger.com. Although it's only been 1.5 year since I switched from Nucleus CMS to Wordpress, I once again switched over to another CMS: Drupal. Not because I was unhappy with Wordpress (it's a really nice system), but Drupal gives me a lot more flexibility. Flexibility which I needed to implement some new ideas I had for this version of the weblog and my website in general.

I have always maintained a few different sites, running on a plethora of applications. I had my photo website (fotos.budts.be), which ran on ZenPhoto; I had lightyear.be with the activity stream, running on Gregarius with some self-hacked ruby code to write the final stream; Then I had my cv-site (budts.be/jeroen), which was mainly just static html with some PHP-hackery; Joining the club was also gluefish.net, which was built with some other static html and PHP-code; and finally I had this weblog on Wordpress. Clearly a mess :)

So now all these sites are integrated in one Drupal site. The cool thing about this is that all my content is now available on the website as real content, or 'nodes' to use the correct Drupal-speak. That's right, blogposts are nodes, normal pages are nodes, photos are nodes, tweets are nodes, delicious-bookmarks are nodes*, project pages are nodes, (allmost) everything is a node. This has the advantage that I can tag nearly everything on the website with the same set of tags so you and I can easily read all of the content about something. And it also allows easy searching.

When we got our new laptops at work (Dell Latitude E6510) we had some various problems while installing our preferred Linux distros on it.

The first problem which we all had was trying to get the screen to work. I could get it to work by booting with the following kernel params xforcevesa nomodeset (I also removed the default quiet splash). Now I just run with only nomodeset, which works without problems for me, but without 3D. Jan has compiled a patched kernel for Ubuntu with 3D support but with less colors.

Then the second problem: scrolling with the touchpad didn't work. To fix this I ran the following commands:

1
2
3
4
56
7
8
9
10

cd /tmp/
wget http://launchpadlibrarian.net/57421117/patch-dell-e6510
sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r)
apt-get source linux-image-$(uname -r)
cd linux-2.6.35/drivers/input/mouse/patch -p0 < /tmp/patch-dell-e6510 
make -C /lib/modules/`uname -r`/build M=`pwd` psmouse.ko
sudo rmmod psmouse
sudo cp psmouse.ko /lib/modules/`uname -r`/kernel/drivers/input/mouse/
sudo modprobe psmouse 

Today we saw the release of Ubuntu 10.10, codenamed Maverick Meerkat. Because I had some time today I immediately decided to upgrade my laptop. As usual the upgrade succeeded without too much trouble. Clicking a few buttons, letting the computer work for about an hour, reboot, and you are pretty much done.

Except for the few small things which break during upgrade. Out of experience from upgrading previous versions I know there are always a few small things you will have to fix. So here are the steps I did after the upgrade:

• The installer disables all your extra PPA's, so when the upgrade has finished I re-enabled those and ran sudo apt-get update && sudo apt-get upgrade again.
• I quickly discovered that Guake didn't use my nice UTF-8 prompt anymore. This turns out to be a bug in VTE. The TERM variable isn't set correctly when launching Guake, so it acts as a dumb terminal. To fix this I changed the method of launching Guake in my startup script. It used to be guake &, and now it is TERM=xterm guake &. Fixed!
• During installation I saw that the upgraded had decided to remove cups-pdf. Simply reinstalling it with sudo apt-get install cups-pdf fixed this. I don't really know why it was uninstalled in the first place.
• To quickly switch between a one screen and a dual screen configuration I used disper (available from a PPA) on Ubuntu 10.04. Disper doesn't work anymore. However, once you have configured your desired dual screen setup once with the 'Monitors' configuration tool, you can simply open 'Monitors' again and ubuntu will detect the correct screen setup (one or two screens). To setup my correct screen setup I had to open the ATI Catalyst Control Center as root and play a bit with the settings. It was a bit of trial and error, but in the end it turns out support for my setup has improved. With Ubuntu 10.04 I could only select 1440x900 as the largest resolution for my second screen and I had one corner (5 by 5 cm) which was always unusable. Now I can select the correct screen resolution (1680x1050) and it looks awesome.
• Because I did an upgrade, some of my settings were kept. I was still using the default ubuntu 10.04 wallpaper, so I manually changed it to the default 10.10 wallpaper (I always like to use the default wallpapers for a while). I also configured the 'programs font' to use the new Ubuntu font, just to give it a try. At first it looked a bit odd, but after using it for a few hours now, I'm starting to like it.

Apart from these small things I really like Ubuntu 10.10 so far. Certainly the upgraded theme looks really good.

While VIM certainly isn't an IDE, there are a lot of plugins in existence to make it more IDE-like. Although I have been working a lot inside IDE's the past few years, I don't really need all those fancy IDE features (and the bloat that comes with it). That's one of the many things I like so much about Vim, I can just add the features I need to the editor. So while there are certainly at least a few plugins to work with projects inside Vim, I came up with my own system for working with "projects" (call them "light-projects" if you wish). One small note: For the moment this method suits my needs, but since I'm only using Vim for about two months as my main editor, this might change obviously.

Basically, my solutions is based on an autocommand for every 'project' and the command-t plugin. Oh, and sessions as well. The autocommand detects when a file is read (or created) inside the project-directory. In this case, it will source the correct 'vimrc-project-file' and setup everything specific for the project. So as an example, suppose we have a project in ~/Projects/foobar/. In my .vimrc I add the following line (to be more correct, for most of the projects I would add the line in my host-specific vimrc-file, as I mostly use one specific computer to work on a specific project):

1

autocmd BufRead,BufNewFile ~/Projects/foobar/* source ~/.vim/projects/foobar.vim

This autocommand simply sources the foobar.vim file everytime a file in the foobar directory is read, or created. Since the foobar.vim project-file is just a regular vim-script file, you can do anything you want in it. I mostly use it to set some editor properties and add some additional mappings, such as:

1
2
3
4
56
7
8
9
10

" I use autochdir by default, but for this project I prefer
" to always be in the project-root. So we first disable the
" autochdir option
setlocal noautochdir 
 " and then we cd to the project-root
cd ~/Projects/foobar/
 
" in this project i like to use ant, so set it up as the make program inside vim
setlocal makeprg=ant\ -find\ build.xml

I have some other options in my project-vimrc file which are more specific to exploring and navigating code, but I will explain these in a later post I plan to write.

So that's it for automatically configuring vim with settings specific to your project when editing one of the files of that project. One other important aspect of working with projects is to be able to easily open any file of your project. Most IDE's have fancy file-explorers, and a lot of vim-users seem to love the NERDtree plugin. But a few years ago, when I found the OpenIt plugin for jEdit, I discovered that I can type faster than search my way through a tree-structure of directories and files. Resharper adds a similar feature to VS.NET (did I already mention that Visual Studio is just crap without Resharper?). Just press a shortcut, start typing what you need, and let the program do the searching.

For vim I found the command-t plugin. After installing the plugin you can launch command-t with <leader>t (unless you have changed your leader key it will be a backslash, so the correct mapping will be \t). Command-T will index your current directory and it's children. The fact that it indexes the current working directory is one of the reasons why I `cd` to the root of a project in my project-vimrc, so while working on a project Command-T will always index my entire project. The first time you launch it, command-t might take a few seconds before the indexing finishes (depending on the amount of files in the directory-tree), but the results are cached, so next time you launch Command-T it shows up almost instantly. Command-T will now show you a list of all the files in your project. Now you can just start typing parts of the filename (or even of the path to the file) and Command-T will filter out the matching files. If the correct file is selected, simply press enter and Command-T will open the file. I really find this a lot easier than hunting down the file myself.

One last feature of Vim I use for projects are sessions. If your Vim is compiled with session-support (it probably is), you can let Vim write a file which contains a list of all the buffers you have opened (and mappings etc which you have defined while editing). When you want to continue working on your project, you can simply instruct Vim to open the session from the session-file and Vim will restore all the opened buffers, mappings etc.

While this is already useful, I think it still requires to many manual actions. No problem, plugins to the rescue! The SessionMan plugin makes all of this a lot easier. The first time you start your project, simply save your session with :SessionSave. SessionMan will notice that you currently don't have a session and ask for a name, so you can enter 'foobar' (if that is the very original name of your project). When you start vim again to continue working on your project you can now simply use the command :SessionOpen foobar to open your foobar session. Also SessionMan will automatically save your session when quitting vim. Another useful command is :SessionList (which I have mapped to ,s). This shows a list of all your sessions and lets your select the session which you want to open.

So in short, when I want to continue working on a project:

• I launch gvim
• I type ,s to open the sessionlist
• I select the correct session
• Vim restores all my opened buffers and windows
• Thanks to the autocommand for the project, vim is correctly setup for the project
• I can quickly open files with \t