Toggling insert/normal mode in vim with CapsLock

You know that CapsLock key on your keyboard ? The sole usage of this key is to SHOUT ON TEH INTERNETS§§§. I decided to disable it completly as I never use it on purpose.

I also wanted to use it in vim to toggle between normal and insert mode with one key instead of the default i/Esc.

Disabling CapsLock

Disabling CapsLock is a fairly straightforward process. The xmodmap program is responsible for binding keyboard events to your software and you can change the default behavior by creating an ~/.Xmodmap file.

Just put the following code in it and the pressing the CapsLock key will no longer block your next keys in Caps.

clear Lock

Catching it in vim

Now, to get it in vim, you'll have a little more work to do. First, CapsLock is not one of the default vim keycodes, so you won't be able to remap it to any useful function. To use it in vim, we will hook it directly on xmodmap to another key, one that is part of vim default keycodes.

I choose the virtual F13 key. Your physical keyboard might only have F keys from 1 to 12, but the internal software seems to be able to react to 37 of them. So, why not using them ?

In your ~/.Xmodmap file, this is as easy as adding the following line

keycode 66 = F13

66 is the internal code for the CapsLock key. We just define that pressing the physical CapsLock key should trigger the F13 virtual key.

Now, in ~/.vimrc, we will tell vim to explictly listen to extended F keys (from 13 to 37) which it does not do by default.

set <F13>=^[[25~

^[[25~ is the special keyboard code sent to vim when the F13 key is triggered. Here we just define that such a keyboard code should be interpreted in vim as an <F13> vim key.

Now, you can use <F13> in your custom vim mappings

Toggling normal/insert mode in vim

vim accepts two kinds of mapping. Those triggered in normal mode (using nnoremap) and those triggered in insert mode (using inoremap).

Here we want that pressing CapsLock (or <F13> in vim as we defined) in normal mode will go to insert mode, like pressing i does. And we also want to get back to normal mode when pressing CapsLock in insert mode, just like pressing Esc does.

nnoremap <F13> i
inoremap <F13> <Esc>l

Notice the l after Esc. It is here to prevent the caret to move back one character when exiting insert mode.

Fixing the shell

One last thing to fix is your shell. By defining in xmodmap that pressing CapsLock would trigger an F13 event, it means that whatever software that react on F13 will now react on CapsLock. Unfortunatly, zsh does react on F13. It insert a ~ character on it (just like it does with F12).

To disable it, we'll simply define a key binding in ~/.zshrc so pressing F13 does nothing.

bindkey -s "\e[25~" ""

Here it is. You can now press CapsLock anywhere and it won't have any effect. Plus, pressing it in vim will toggle insert/normal mode.

Getting the list of Facebook pending requests of a user

Getting the list of pending facebook requests of a user a few weeks back was as easy as calling https://graph.facebook.com/me/apprequests?access_token={user_access_token}

We discovered around the 1st October that some of our requests were failing in production, without any more clue than some "OAuthException : access_token invalid" messages in our logs.

It appears that FB changed the way their endpoint react to /apprequests call. Of course, they didn't bother telling us.

The previous url does not work anymore. Switching the user accesstoken to the app accesstoken as documented does not work (as usual with FB documentation). It returns an error.

Instead, the following call wil yield the correct result : https://graph.facebook.com/{user_id}/apprequests?access_token={app_access_token}

Increasing VirtualBox hard drive size

While trying to import a huge (1.7Go) mysql dump file into my VM I was blocked by mysql telling me that not enough space was left on the device to complete the operation.

As I was running a VM, I thought it would be a simple matter of increasing the virtual hard drive size.

Turns out it wasn't that simple. After much trial and error, here is how I finally did it.

Creating a new hard drive

VirtualBox let you easily add new devices, such as hard drives to your VM. I simply created an empty 120Go hard drive and booted my VM.

Here, under Ubuntu, I cloned my current hard drive to the new one using :

sudo dd if=/dev/sda of=/dev/sdb

Fixing the guest partition

Once finished, I opened Gparted, selected /dev/sdb and saw that I had 112Go unallocated. I couldn't easily add them to the initial partition as a swap partition was in the way.

I finally decided to remove the swap partition and resize the initial one to the (almost) complete size of the hard drive.

I left 1Go free in case I ever needed to create a new swap partition later to fix the one I deleted.

Then, I closed the VM. Get back to VirtualBox panel and remove the original drive, keeping only the new 120Go one.

One reboot later, my Ubuntu was proudly displaying its 120Go.

Checking potential throttling from Orange

Starting a few weeks back, we started having painfully slow ssh connections at work. Our servers are hosted on the SoftLayerinfrastructure, which are extended on all North American territory, but we are based in France.

We have fiber-optic connection here, almost every other connection is blazingly fast. Except connections to our own servers...

Call me paranoid, but the first idea we got was that we were being throttled by our provider. Orange is infamously known for degrading on purpose connection with some know hosts.

A colleague was browsing through his own secure tunnel, going through his personnal server for every outgoing communication.

And his connection was as fast as it should be.

That made us wonder. How a tunneled connection could be faster than a normal one ? The cost of crypting data should have slow the request down. It had the opposite effect, rendering the request in the expected time.

I created a garbage file using the following code and used scp to send it from one server to another, to test bandwith.

dd if=/dev/zero of=garbage.bin bs=100000000 count=1

Nothing interesting came out of it. I had a impressivly fast connection between our fiber connection and OVH (up to 50Mb/s) and slow connection to SoftLayer.

So, for the time being, I'm connecting to SoftLayer through OVH and even if it made me use one more tunnel, it is still far more fast than a direct connection.

Sansa Clip+ folder merging issue

I own a Sansa Clip+ as my mp3 player. It's really small, has great audio quality and combined with a 32Go microSD card plus the internal 8Go, it's enough to hold almost all my music library.

As with any mp3 player realeased nowadays, you can browse your files using mp3 tags. I don't really like it and feel limited in my browsing. As I'm listening to a lot of movie soundtracks I have a pretty long list of artists with only one song attached.

Fortunatly, the Sansa also allows you to browse by folders, which is rare enough to be highlighted.

So far so good. Except that I've discovered a little bug a few days ago in the way folder navigation is done.

I had two folders named Soundtrack - Games and Soundtrack - Movies. Each were holding a dozen albums. In each of those folders I had subfolders sharing the same prefix, like Hitman Contracts, Hitman Blood Money or Kill Bill and Kill Bill volume 2.

When browsing my music folder on the Sansa I noticed that the Soundtrack - Games folder had disappeared. I check the SD card in my computer, and it really was there.

I finally discovered that all the Sountracks - Games content had been merged in Soundtracks - Movies resulting in one big directory instead of two smaller ones.

My second discovery was that all my Hitman sub folders were also merged into Hitman Contracts, and my Kill Bill music was in Kill Bill volume 2.

It seems that when multiple directories shared the same prefix, all folders will be merged in one whose name is the last in alphabetical order.

I'm not the only one in this case, I saw a similar report on Sandisk forums, but the bug seems erratic. Folders does not always get merged if sharing a prefix.

As a temporary fix, waiting for a regular fix in a firmware update, I'll update my folder tree to use Soundtracks/Games/Hitman/Contracts and Soundtracks/Movies/Kill Bill/Volume 1 but this is far from optimal.