On Vim

I just read Brett Hoerner's blog post entitled "On Emacs" and it yielded a response from me!

Let me start by saying that I love vim for numerous reasons, but here are the major ones:

  • vim makes amazing use of the home row
  • SUS and POSIX make it one of the most widely available editors to ever grace a terminal
  • vim is modal, meaning you're in one mode at a time (e.g. insert mode versus command mode)

I used to use Emacs. I've got nothing really against it. Emacs gets things done. It's just that in my opinion, vim gets things done faster.

I'm in love with not taking my hands off the home row. In Xmonad, all of the key bindings are based on Alt, meaning my thumb can tap Alt, while my other fingers rest on the home row. That means I can transition between editors and windows and make changes while usually never having to leave the home row. Examples of this include a key sequences like dd, Alt+k, etc. I've even got the key sequence 'jj' bound to be ESC, so that I don't have to reach for the escape key.

This can be contrasted with Emacs using an example: text search. Search for the word "cat". Emacs: C-x-s cat. Vim: /cat. No reaching for Control, which puts your fingers in an awkward position and off the home row, no key sequence, full regex support off the bat, and so on.

Brett makes a great point in his post, stating that step 1 of using Emacs is to customize it. Unfortunately, when I learned Emacs in the mid-90s, my step 1 was learning to navigate, learning to copy/paste, etc. That time period made it especially hard to get information on how to customize it. And despite the advent of good search engines, I think this still holds: users coming into Emacs are overwhelmed just trying to get things done and don't "have time" to customize things they don't like. Customization comes later.

Brett makes another excellent point in stating that editing a vimrc is difficult. I feel Emacs/Elisp are equally at fault here. I've found that one's ability to customize their Emacs or Vim config is directly correlated to the size of their beard. I have a small beard, and assuming that correlation is causation, I thus limiting my ability to edit my vimrc with changes that I'd really find useful (example: some-key-combo => auto-format all source code in file; Eclipse, I'm looking at you!) And don't newbs find more sense in vimrc speak? Assuming you don't learn Lisp prior to your Emacs years, Emacs configuration can be pretty daunting. But, I bet 99.9% of all vim users can read a vimrc file with some semblance of understanding. Moreover, I bet those same people can copy/paste portions from other vimrc files and get up and going a bit more quickly.

Besides all of these efficiency things, one must also consider the breadth of the vi/m install base. I can go to any *NIX terminal booted after I was born and find some flavor of vi. This isn't the case for Emacs.

Lastly, we've got modal editing. This is where vim really shines, in my opinion. Insert mode is for inserting. There are tons of little conveniences for popping into insert mode in vim, often only differing by how they place the cursor. And those conveniences are available for every command mode command I'm aware of. Add visual mode onto this, and you've got the complete package for navigating while editing quickly. The part that turns people off is switching between modes quickly. They don't know all the nuance shortcuts that make going from visual mode to insert mode to command mode extremely fast. People tend not to learn these because modal editing confuses them, so I think there's a wall that people hit when they want to advance beyond i => ESC => hjkl => i => ESC => repeat. 0, $, ^, d$, d0, yy, dd, p, P, {, }, n, N, v, etc. These are all important basic commands that are really what add productivity. If a user fires up vim and exclusively uses i, h, j, k, l, the experience is going to suck. It's the commands that move between modes that make vim sparkle. Also, as I said, binding 'jj' to ESC helps a lot. In Emacs, since there are no such modes (there are modes, but the term mode means something different in the Emacs context) performing all of these operations must be a much more complicated key sequence. By simply wrapping a context around a key, we avoid long key sequences and command keys altogether.

Just my two cents :D


Obtaining a beautiful, usable xmonad configuration

I've spent a lot of time perfecting my workspace; I spend a ton of time at a computer, and so I'm extremely invested in how my tools perform. A window manager is a pretty important tool, and my window manager of choice is xmonad. Over time, I feel my xmonad configuration and setup has evolved into something really nice.

Why would someone use a tiling window manager like xmonad? The short answer is usually efficiency. People spend a lot of time organizing windows, and using their mouse. If you could instead never take your fingers off the keyboard (for the most part,) your efficiency would go up. This won't be true at first as people learn key bindings, but after awhile you become drastically faster at the mundane parts of computing, like switching between windows, or organizing them in different ways. This approach is definitely more minimal, but I'd recommend this if you spend your day in vim, emacs, terminals, or other text-heavy applications. Even Gmail has key bindings so that I don't have to touch my mouse.

Other perks of using xmonad include things like xmobar, which is surprisingly useful, as it gives tons of information about the state of xmonad, your system, and your local weather, without being at all intrusive. To start programs, you'll want to use something like dmenu, which auto-completes command names as you type.

If you've never used xmonad, then this post is intended to help you get going. Otherwise if you're an avid user, then this post will give you a consistent, good looking setup that you'll hopefully find usable and better than the xmonad defaults.

Here's a screenshot from my workstation:

I've heard a few comments on how nice everything looks, so I took some time to release the necessary configuration files and scripts in a github project. Why is this nice? Because the color scheme is consistent, the layouts are scalable, and the key combinations are standard. If you use the IR_Black theme for vim or your terminal, you'll notice even more consistency throughout.

I'll run through really quickly how to set this up.

This set of configuration and scripts has the following requirements, but should work with other versions of these requirements (minor modifications required for older versions of xmonad or xmobar.)

  • xmonad 0.9.1 or 0.9.2
  • xmonad-contrib 0.9.1 or 0.9.2
  • xmobar 0.11.1 or 0.13
  • trayer 1.0
  • dmenu 4.0
  • yeganesh 2.2
  • scrot 0.8

To install these on an Arch Linux machine, run:

sudo pacman -S xmonad xmonad-contrib xmobar trayer dmenu scrot \
cabal update
cabal install yeganesh

Next, clone the github repository:

mv .xmonad .xmonad.orig
git clone .xmonad
echo "export PATH=\$PATH:~/.cabal/bin:~/.xmonad/bin" >> ~/.bashrc
source ~/.bashrc

Now all you have to do is start xmonad. The way you do this will vary, but if you're using something like SLiM, then just use the .xinitrc provided with the configuration you already downloaded:

mv ~/.xinitrc ~/.xinitrc.orig
ln -s ~/.xmonad/bin/xinitrc ~/.xinitrc

Adjust ~/.xinitrc as needed (e.g. if you don't use Google Chrome or xscreensaver.)

That's it! You should now have a desktop looking like the screenshot above.

If you're new to xmonad, the key combinations can be daunting, so here are some of them to get you started:

  • Alt+p: Run dmenu. After it's running, start typing a command and hit enter
  • Alt+Shift+Enter: Launch a terminal window
  • Alt+1, Alt+2, ..., Alt+9: Switch to workspace N
  • Alt+w: Switch to the left screen
  • Alt+e: Switch to the right screen
  • Alt+j or Alt+Tab: Switch to the next window
  • Alt+k: Switch to the previous window
  • Alt+Space: Cycle through layouts for the current screen's windows
  • Alt+Enter: Make the currently active window a master window
  • Alt+,: Increase the number of windows in the master area
  • Alt+.: Decrease the number of windows in the master area
  • Alt+m: Switch to the master window
  • Alt+Shift+j: Move the currently active window forward in the layout
  • Alt+Shift+k: Move the currently active window backward in the layout
  • Alt+l: (That's an L.) Make the master area window bigger
  • Alt+h: Make the master window area smaller
  • Alt+Ctrl+l: (That's an L.) Lock the screen with xscreensaver
  • Alt+Left Mouse Button+Drag: Untile the selected window and move it
  • Alt+t: Move the currently active window back into tiling
  • Alt+Right Mouse Button+Drag: Tile and resize the selected window
  • Alt+q: Reload the xmonad configuration
  • Alt+Shift+q: Exit xmonad

People are sometimes intimidated by all of these shortcuts and the new style of interface. Remember that the currently active window will be surrounded by a red border. Also, there are a series of layouts you can use. Alt+Space makes cycling between them easy. I recommend you write the key combinations down or print them out, that way if you forget you won't be stuck. For things like watching a movie, just fire up mplayer and hit 'f'. Fullscreen mode works just fine. Otherwise if you don't want to fullscreen and you don't want to tile the video, just Alt+Left Click+Drag, as described above.

Once you are all setup you should:

  • Modify ~/.xmonad/xmobar.hs to show the correct weather for your location
  • Modify ~/.xmonad/xmonad.hs and ~/.xinitrc as needed if you don't use xscreensaver, Google Chrome, etc.

For further reading, see:

Let me know if you have any questions, I hope this has made xmonad better for you!

Update (Jun 28): Mats Rauhala / MasseR has been kind enough to improve the bin/dmenu script to not crash some systems. +1 to him :) I've merged his changes into the github repo mentioned in this post.

Update (Nov 12): An anonymous user pointed out the github clone URL I gave was wrong. They were right, I've fixed it.

Update (Sep 11 2011): Updated installation instructions for latest version of configuration in repository. Also :%s/Xmonad/xmonad/g.


Better fonts in your terminal, vim, etc

If you're like me and you spend all day staring at text on a screen, there are numerous things you consider important. Of those things, readability is paramount. I've adopted a favorite configuration of fonts that I find so beneficial that I thought I'd share. Here, I'll discuss the Envy Code R font and how to make it good on an LCD monitor.

I run Arch Linux, so I'll describe how to do everything here in Arch, but most of it is applicable to other distros. Before we begin, we'll be using some packages out of the AUR, so your first step is to install packer, an AUR helper.

tar -xzvf packer.tar.gz
cd packer
# The following may be slightly different if the version changes
sudo pacman -U packer-20100622-1-any.pkg.tar.xz </pre>

There are many programming fonts to choose from. My favorite is Envy Code R, but yours might be different. Here are some popular fonts you can choose from that all have AUR packages:

For some really good font reviews, see Hivelogic and thatwebguyblog.

Once you've settled on a font that you like, install it with the following command, replacing the package name as appropriate.

sudo packer -S ttf-envy-code-r

Fire up your terminal and select your new font. If you use gnome-terminal, that means right click on your terminal, select Profiles > Profile Preferences, click on the button next to Font:, and select your new font. On a 1680x1050 LCD, I find the ideal size for Envy Code R is 10pt regular. In gnome-terminal, you should see the font change immediately after hitting OK.

You might be thinking "it's a little fuzzy." If so, it's because anti-aliasing is turned on, and you don't want it turned on for a programming font like this. This is pretty quick and easy to fix. The following steps are taken from the Arch Linux Font Configuration Guide. Skip this step if you're on a CRT.

sudo pacman -Rd libxft cairo
sudo packer -S fontconfig-lcd cairo-lcd
sudo pacman -S libxft-lcd

Now that we've got LCD patched packages installed, let's disable anti-aliasing for our new font.

mkdir ~/.fonts.conf.d
vim 10-no-aa-envy-code-r.conf

In the file 10-no-aa-envy-code-r.conf, paste the following XML and save.

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<match target="font">
  <test name="family">
    <string>Envy Code R</string>
  <edit name="antialias" mode="assign">
  <edit name="hinting">

If you're not using Envy Code R, replace as appropriate with something like "Inconsolata-g" or "Droid Sans Mono". Be warned, Inconsolata-g looks bad without anti-aliasing, at least on my screen.

Once the file is there, restart your terminal, and voila: you should have no more fuzziness.

Let me know your favorite fonts and configurations, I'm always looking to improve my setup!

Example of Envy Code R


Google I/O 2010

You can find me at Google I/O 2010 today and tomorrow. If you've a burning question about Google Apps For Your Domain, Spreadsheets, Sites, Documents List, etc., here's your chance to ask me face to face!


New look and feel

I've switched from TextPattern to Typo. So far I'm loving the change. I'd been wanting to switch to Typo a long time ago, but either never got a theme going that I liked, or I didn't take the time to set it up in my production environment.

Things seem to be running much faster. I think this might be because of DreamHost's use of Passenger for Rails apps. The caching by Typo also seems to be better than TextPattern's. I've still got support for Textile, but have a much better look and feel, and easier to manage UI. Comments are better spam filtered now, so they should automatically post most of the time.

This design is adopted from the Lead WordPress Theme. I love its minimalism, I'm much happier with how things look now. I had to migrate the theme for Typo, which was actually pretty easy. If you'd like a copy of the theme, let me know.

I've also added support for syntax highlighting for my code samples using SyntaxHighlighter. It's wonderful, except that, in order for < and > characters to be rendered correctly, I have to wrap the code in script tags, which do not degrade well. Regardless, I like how it looks, much better than before with just using raw pre tags. Here's a sample of the new highlighting:

class Speaker:
  def speak(self, message):
    print message

if __name__ == "__main__":
  s = Speaker()
  s.speak("Hello world!")</pre>

I've updated the About page with more ways to follow me and some new contact information.