Unfortunately, the window$ version of Vim searches different paths for configuration files than the Linux version does. That means that even though there probably is a git version for window$, it won’t help us much as window$ doesn’t know softlinks. So we must use a little trick…

When I’m forced to work under window$, I install Cygwin to make the work a lot more enjoyable. It has packages for practically everything I need, the most important of which is a usable terminal. Unfortunately, the Linux file system it simulates conflicts with window$’ own one, so there typically arise problems when using an editor started from this environment.

To make things worse, Cygwin has problems with ntfs’ file properties (ownership and access rights) and with handling the different line endings of Linux and window$ files. Therefor, I prefer installing the window$ version of Vim which does not suffer from these problems. Of course, I still want to use the same settings for it that I use on my PC at home…

Coping with textmode hassles

This is very important! You need to make sure that the directory you check your settings out to is mounted in binary mode. Otherwise, you won’t get much further than checking out: The first commit, branch or tag you do will completely screw up your git directory as it cannot deal with textmode’s line endings (aka <CR><LF> instead of just <LF>, check out the Cygwin website for details).

If you use textmode per default, you at least need to mount the directory into which you will check out your configs in binary mode. Doing this is easy in Cygwin. You can see your mounted directories with mount and the respective commands with mount -m. The important flags are -t for text- and -b for binary mode.

As an example, let’s assume you want to mount User’s $HOME directory in binary mode:

mount -f -s -b "C:/cygwin/home/User" "/home/User"

Getting the window$ version of Vim to use your settings

I assume you still know how to retrieve the settings via git from the first part of this mini-series, so I’ll skip that as it works just the same way under Cygwin. Once you’re done, rename the file C:\Programs\Vim\_vimrc and create a new file with the same name and edit it:

set runtimepath+=C:\cygwin\home\User\.config\vim\.vim
set runtimepath+=C:\cygwin\home\User\.config\vim\.vim\after
source C:\cygwin\home\User\.config\vim\.vimrc

Replace User with your username under window$ and the next time you start the window$ version of Vim, it should use the settings imported with git.

Have fun!

• My PC at home
• My laptop
• My girlfriend’s PC (also running Arch, of course) on which I regularly need to do administrative work
• The Arch live system on a USB stick
• My PC at work

Now, in each of these work places, I regularly modify configurations or even add new ones. What has always bugged me is that I have a hard time synchronizing these changes. So I thought: How about employing a revisioning system to do the work for me?

Which system to use?

At first, I wanted to use subversion, as I already got used to it during my diploma thesis and got even more experience from using it everyday at work. But then I remembered that I had read about git and how great it was supposed to be and indeed, it has some advantages over subversion for my plans.

The most important one is that it is a distributed system, meaning that I could pull from any workspace, instead of just a central repository. This could come quite handy if I only got my laptop with me or my PC at home isn’t running, but the one of my girlfriend is. Not to mention how helpful this is when my desktop PC should crash!

Directory layout

Now that I decided which tool to use, I needed to decide how to layout the directory structure. My first idea was to simply create a repository inside my $HOME under which I could add all my config files. But that would have forced me to always check out the configuration files of all tools I’m using at the specific computer I’m at instead of only the ones I need.

So I created a subdirectory under my $HOME and added another subdirectory for each tool whose settings I’d like to keep track of. That’s when I noticed that many tools already use the $HOME/.config directory for exactly this purpose and so I did as well. The layout now looks like this:

$HOME
 + .config
  + vim
  + bash
  + ssh
  + ...

To have the respective tool find the config file, I just add a softlink (remember to remove/backup the original files first):

ln -s $HOME/.config/bash/.bashrc $HOME/.bashrc
ln -s $HOME/.config/vim/.vimrc $HOME/.vimrc
ln -s $HOME/.config/vim/.vim $HOME/.vim
# and so on, I think you get the idea...

Using git

I don’t want to give a full tutorial to git here, but the following should be enough to help you getting started. As an example, let’s set up a repository for bash based on an existing .bashrc file:

mkdir -p $HOME/.config/bash
cd $HOME/.config/bash
git init
cp $HOME/.bashrc .
git add .bashrc
git commit -m 'Initial commit'

That’s it! You successfully initialized your first repository. To check it out from another PC, I use ssh, for which a server obviously needs to be running on the machine which we want to check out from:

cd $HOME/.config
git clone ssh://User@Server:Port/~/.config/bash bash

Replace User, Server and Port with your username on the server, the server’s url or ip address and the port on which the ssh server is listening, respectively. If your username on the server is the same as on the client, you can skip it, just as you can skip the port specification if the server is listening on port 22. To make your life easier, you can preconfigure these settings in the $HOME/.ssh/config file. See man ssh_config for details on how to do this.

This concludes the first part of this tutorial. I definetely plan to give some examples about how to fetch and push changes with git. See you then, if you’re interested.

However, the flat is now pretty much livable, though far from being completely furnished. Luckily, I do have some time updating the blog again. So brace yourself, new experiences coming in. Have fun!

What I like about Vim

• Completion
  The C++ auto-completion (omnicomplete) is not only much easier to install and set up than anything I’ve found for emacs, it also actually works. The closest comparable thing for Emacs is Cedet, which not only bloats emacs’ gui and makes it take even longer to start, it also relies on etags. etags is an emacs version of ctags, the latter of which creates tags files needed for Vim’s omnicomplete to work. Why the developers of emacs chose a different (to me seemingly non-standard) tool for is really a mystery to me.
  Moreover, Vim supports a drop-down completion menu out of the box! I know there are scripts for Emacs which do the same, but again, these are difficult to install and also don’t work when using Emacs on the command-line. In Vim, this works exactly the same, be it in gvim or the console Vim.
  Finally, Vim supports completion for different types of objects: You can have Vim complete words from open buffers, words from dictionaries, words from omnicomplete or filenames, just by pressing a different key combination. This works, and it works great!
• Movement
  Some of Vim’s movement commands are just incredibly awesome! I can’t sum them all up, but just to give you an example, the “cib” command – standing for “change inner block” – deletes the contents of the innermost ()-block the cursor is in and positions the cursor so that you can replace it. This is such a time-saver that I hardly believe I’ll ever want to live without it.
  These movements become even more powerful when it comes to scripting (see next item), where you can use them to step over text objects generically.
• Scripting
  Emacs uses the extremely powerful lisp dialect elisp for scripting and extending Emacs functionality. The downside is that to use it, you obviously need to know lisp, which certainly not everyone does. I learned some Common Lisp, but as interesting as it was, I didn’t know where I could actually utilize it and so I never got to train it and kept but the mere concepts of functional programming in mind.
  Vim’s scripting language on the other hand is relatively easy to learn, as it much resembles other scripting languages such as perl or python. Even after this short time, I’ve managed to write my first few short scripts which help me in everyday programming. For instance, I wrote a function which generically converts a C++ function declaration to a function implementation body.
• Getting help
  Both Emacs and Vim do have a vivid user base who you can contact if you have questions. But often, you just don’t have the time to search the web or hang around in an irc chat. I found that practically all questions I had about Vim could be answered by visiting www.vim.org or using the superb builtin help functionality. I never found Emacs’ help to be even half as helpful.

What I dislike about Vim

• Inconsistent movement
  Once you got used to Emacs’ movement keys (e.g. C-n for down, C-p for up, etc), you use those everywhere, no matter what you’re currently doing. This enables you to keep your hands on the main key field of the keyboard, greatly increasing your typing speed while programming.
  In Vim, the cursor movement highly depends on the mode you’re in. When in normal mode, you use the hjkl keys to move the cursor around, but in insert mode, these of course produce the respective letters, forcing you to use the cursor keys if you need to correct a mistake.
  There are some alternatives for solving this problem, none of which I find very attractive. The first was suggested by a fellow Arch user, alterecco: He has defined a key mapping, in which the hjkl keys are bound to the respective cursor keys and a key to switch between this and the standard mapping. This has the advantage that you can use the hjkl keys as cursor keys in every application, but you need to find a well-reachable key (or combination therof) to switch the mappings. This key of course must not be used by other applications and porting this behaviour to the different environments you’re working on might prove difficult.
  The other alternative is presumably the classical Vim way: If you make a mistake, you don’t go back to correct it right away as that would break your workflow, but continue typing until you’re done with that sentence/paragraph/block/whatever. Afterwards, you go back to the error in normal mode and correct it. This is the way I’m currently trying to get used to, but for now, it just doesn’t “feel right”…
• Indentation
  Vim has pretty many options for configuring C++ indentation rules. But it still is a limited set of options and as far as I see it, if you want something that is not covered by this set, you got a problem.
  Emacs syntactically analyses your code and thus it is easy to configure another indentation behaviour for any place in your code. I find this to be superior to the way Vim handles this, although it covers most of what I need.
• Shell mode
  Bash, the default shell of most linux distributions, uses emacs key combinations out of the box, but can also be configured to use Vi ones. I’m still trying out the latter ones, but until now, it seems to me that a) the emacs feature set is much more complete and it b) feels much more “natural”.
  I know this isn’t a problem of Vi(m) (if at all), but to me, it belongs to the same topic, as I don’t want to switch editing modes in my mind when switching from editor to shell.

This concludes my preliminary observations of Emacs versus Vim. I hope there are some people out there who might find this helpful. Me, I’m going to continue using Vim until I find a real reason to switch back. Until now, the advantages outweigh the disadvantages by far.

Have fun!

Edit: A friend of mine told me that he could not visit the linked thread on the Arch Linux forums. Unfortunately, I found out that this does not only concern him, but everyone not registered on these forums. The offtopic forum there cannot be looked into without being logged in. Sorry for that!

Even worse, ATI isn’t supporting Linux anymore, they are only supporting Ubuntu and maybe OpenSuse, merely releasing new drivers matching the kernel versions included in the releases of these distributions. As a user of the rolling-release distribution Arch Linux, I have but two choices when new kernel versions come out: Using one of the open source drivers (each lacking certain features such as energy-saving, tv-out or compositing support) or using modified binary drivers.

Concerning the latter, the Arch Linux community has once more impressed me very much. People try to get these drivers to work and are actually quite successful, especially regarding the fact that they neither wrote the drivers, nor are paid for this work. I wonder if ATI watches the famous AMD/ATI Catalyst Bar & Grill for inspiration and tips on their future driver releases…
Nevertheless, the aforementioned busy Archers don’t have access to the driver sources and so even they can’t solve all the problems arising with each new kernel version. And so I – like many other ATI users – had to live with many inconveniences while using them, including not being able to play WoW under Linux, regular manual reinstallations of the drivers and irregular system freezes…

I’d like to note what finally changed my mind to switch back to nVidia although not being a cheap decision: Recently, I met a former lecturer of mine and told him about the situation with the ATI drivers. He told me that he applied at an ATI factory in Germany in 2002 and ATI was talking about opening their drivers even at that time! And then he added that the factory doesn’t exist anymore. I didn’t want to continue looking at such a “promising” future and ordered the nVidia card few days later.

Anyway, the good news is: The nVidia card is working great out of the box! Finally, I can play my favourite game WoW inside my favourite operating system once again. TV-out is working without any hassle, I have options in a graphical dialog I didn’t even touch yet And the card is really quiet when idle. Now the only thing left is to get rid of the ATI card.

The “workaround” version of my script relies on the .conkyrc file to insert an empty line between the todo’s and the appointments. If you don’t need such a line, you can skip reading the rest of this blog entry. All others need to patch the script. First, edit your .conkyrc to call the script only once, but with the parameters for both the appointments and todo’s:

${execpi 300 calcurse -d14 -t | ~/.conky/calcurse_task_to_conky.pl}

Then, save the following patch as ~/.conky/new_version.patch:

5,12d4
< sub spacer
< {
<     if( ${ (\scalar keys %inited) } > 0 )
<     {
<         print "\n";
<     }
< }
<
25,26d16
<             spacer();
<
49,50d38
<             spacer();
<

Finally, apply the patch:

patch -R -i ~/.conky/new_version.patch ~/.conky/calcurse_task_to_conky.pl

That’s it! Now the appointments and todo’s always have a separating line between them.

Of course, he has a certain point about this. I countered that this is only the case if that person is really looking at the header file, instead of the implementation file, leading to the fundamental discussion mentioned above. In the end, I was able to convince him that the pimpl-pattern is useful by three arguments. But before enlisting them, let’s look again at how the pimpl-pattern can be implemented in C++.

You might declare a class like this:

// header file for Widget class
#include "gadget.h";
 
class Widget
{
 public:
  // public interface of Widget //
 private:
  float _topLeftCoordinates[3];
  float _bottomRightCoordinates[3];
 
  Gadget _gadget;
};

A typical class definition. Now let’s see how the class would be declared employing the pimpl-pattern and the boost library:

// header file for Widget class
#include <boost/shared_ptr.hpp>
 
class Widget
{
 public:
  // public interface of Widget //
 private:
  boost::shared_ptr<struct WidgetPrivate> _pimpl;
};

The interesting part of the implementation for this example would look like this:

// implementation file for widget class
#include "widget.h"
#include "gadget.h"
 
struct WidgetPrivate
{
  float _topLeftCoordinates[3];
  float _bottomRightCoordinates[3];
 
  Gadget _gadget;
};
 
Widget::Widget( /* constructor parameters */ )
: _pimpl(new WidgetPrivate)
// rest of the constructor's implementation //

This little example demonstrates all advantages about the pimpl-pattern:

• It makes the public interface to a class easier to identify: When a class is implemented in terms of the pimpl-pattern, all a reader needs to filter out is the line where the private object is declared. Everything else is part of the class’ interface and thus important to the reader. On the other hand, the actual implementation of the class is hidden from the user, making him rely on the interface, not the (assumed) implementation of the class, which might change over time.
• It reduces compile time dependencies: By moving non-trivial object instanciations (here: _gadget) – which need to be allocated and therefore defined on object construction – to the implementation file, we need only very few includes in the header file. This results in less compile-time dependencies, reducing compilation times.
• Last, but not least: A class implemented with the pimpl-pattern can be easier adapted to use the lazy-copying algorithm. As the complete state of each object is encoded in a separate structure (here: WidgetPrivate), it suffices to have a copied object refer to the original’s private implementation as long as there is no write-access to it. This can save a lot of time!

One of the disadvantages of this pattern has been mentioned above and I’d like to mention the other as well: Every access to a class’s private members now incurs another indirection. Depending on how often the functions of your class are used, this might result in a noticeable run-time cost. However, according to the famous 80-20 rule, this disadvantage won’t affect many classes…

In case you wondered: Of course the pimpl-pattern can be implemented without boost just as well. It’s just that with boost’s shared_ptr implementation, we don’t need to worry about deleting our private struct as opposed to using standard pointers and won’t get compiler warnings as opposed to using std::auto_ptr (which doesn’t like forward declared structs/classes).

Xappe presented his theme on the Arch Linux Boards where I saw it and tried it out immediately. I was annoyed by gdm’s many dependencies anyway… Following the “true” Arch way, I created a simple PKGBUILD, enabling me to install and uninstall it via Arch’s package manager pacman. After having posted it in the aforementioned thread, Xappe drew my attention to the missing dependency on the imagemagick library.

So I started overhauling the PKGBUILD and the package at the same time. imagemagick is a rather large library, which I didn’t find suitable for a theme to such a minimalistic login manager. That’s why I modified the theme so that it automatically tries to set the background with imagemagick, feh and xloadimage which are all optional dependencies to the package now. If none of these are available, it will just set a black background without emitting an error.

You can find the package at the Arch User Repository and the thread on which it was originally posted on the Arch Linux Boards.

Have fun!