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

Published on Tue, 29 Jun 2010 05:09 UTC
2 comments

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:

Screenshot of my Xmonad setup.

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
  • xmonad-contrib 0.9.1
  • xmobar 0.11.1
  • trayer 1.0
  • dmenu 4.0

To install these on an Arch Linux machine, run:

$ sudo pacman -S xmonad xmonad-contrib xmobar trayer dmenu

Next, clone the github repository, and copy the files around to their correct locations:

$ cd
$ git clone git@github.com:vicfryzel/xmonad-config.git
$ mv .xmonad .xmonad.orig
$ mkdir -p ~/.xmonad ~/bin
$ cp -R xmonad-config/xmonad/* ~/.xmonad
$ cp -R xmonad-config/bin/* ~/bin
$ chmod +x ~/bin/*
$ echo "PATH=\$PATH:~/bin" >> ~/.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 this .xinitrc:

xsetroot -cursor_name left_ptr &
xrdb ~/.Xdefaults &
xscreensaver &
~/bin/tray &
gnome-terminal &
gnome-terminal &
google-chrome &
xmonad

...adjusting 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're all setup you should:

  • Modify ~/.xmonad/xmobar to show the correct weather for your location
  • Modify ~/.xmonad/xmonad.hs 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.

Published on Sun, 27 Jun 2010 07:11 UTC
6 comments

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.

$ wget http://aur.archlinux.org/packages/packer/packer.tar.gz
$ tar -xzvf packer.tar.gz
$ cd packer
$ makepkg
# The following may be slightly different if the version changes
$ sudo pacman -U packer-20100622-1-any.pkg.tar.xz

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.


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

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 like shit 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

Published on Wed, 23 Jun 2010 04:15 UTC
0 comments

RailsConf 2010

Steve Bazyl and I will be speaking at RailsConf 2010.

http://en.oreilly.com/rails2010/public/schedule/detail/14510

We’ll be discussing Google APIs, OAuth, OpenID, and how you can become a vendor in the Google Apps Marketplace. Hope to see you there!

Published on Sat, 05 Jun 2010 06:25 UTC
2 comments

End of an era

I'm now officially redirecting shellsage.com to vicfryzel.com. It marks the end of an era, as I've used shellsage.com since February 22, 2004, and it used to look like this!

Published on Sat, 05 Jun 2010 06:05 UTC
0 comments