essays on SWiK

Coming home to Vim

Fri, 10 Oct 2008 10:17:20 -0700

Over three years ago, I was faced with a dilemma. I had recently switched to the Mac (from Linux) and was still using my text editor of choice (vim), but at the time, vim’s “integration” with OS X was pretty minimal (and that’s putting it optimistically). I experimented with emacs, but it never clicked for me, and honestly, emacs on OS X wasn’t all that better than vim at the time. Sadly, reluctantly, I said good-bye to vim and switched to TextMate.

TextMate was (and certainly still is) a fantastic text editor. The project drawer was awesome, finding files via cmd-T was super powerful, and smarter auto-completion and snippets promised a new and faster way to pound code. After a couple of months of reteaching my fingers how to edit text, I was happy.

Sometimes, though, late at night, I would think again of vim.

Fast forward three years. The vim landscape is different now. There is actually a Mac-friendly GUI version of vim now, MacVim, which actually looks like it belongs on OS X. Vim 7 supports UI tabs, and a much more powerful auto-completion mechanism than before. And plugins like rails.vim and fuzzyfinder.vim mean that TextMate no longer has a corner on powerful project navigation.

For the last few weeks I’ve been toying with switching back to vim. TextMate’s “snippet” feature never clicked for me, and the only times I used it were by accident (when it annoyed me more than it helped me), but I really was hooked on the project browser, and cmd-T, and a few other things. I realized that, with a little work, perhaps a way could be found to reimplement most of the things I loved about TextMate, in vim.

This last week I’ve worked exclusively in vim, to test that theory. It’s like coming home. As I said, TextMate is a powerful and wonderful editor, too, but differently powerful and wonderful. Vim’s wonderfulness and power is the wonderfulness and power of git, or linux, where the learning curve is steep (ridiculously steep at times), but the rewards of mastery are sublime. I didn’t even realize I had missed a sane shift-J, or using the dot key to repeat the last command. Fix transposition typos with ‘xp’. Select a single word with ‘viw’. Drop bookmarks with ‘m’, and jump right back to them with single quote.

If any of that makes your stomach roil, then vim is not for you. :) But to me, it’s like being embraced by a long-lost friend after years apart. And vim holds no grudges.

There was still the issue of the TextMate features that I had particularly come to love. First to tackle was cmd-T, since my workflow had become so dependent on that for finding files. Takeshi NISHIDA’s fuzzyfinder.vim script seemed like exactly what I wanted…at first. It’s definitely a powerful tool, but the fuzzy finder for files was not TextMate’s cmd-T, and my instinctive attempts to treat it so were causing me a lot of aggravation.

So I took an evening and wrote fuzzy_file_finder, a Ruby library that mimics (and improves on, if I do say so myself) TextMate’s cmd-T functionality. Then, I extended fuzzyfinder.vim with fuzzyfinder_textmate, which bound the fuzzy_file_finder to vim. The result?

See for yourself: http://s3.amazonaws.com/buckblog/videos/fuzzyfinder_textmate.mov (600K, QuickTime video).

I’m still working on a solution for the project browser. Yes, I know there are several (“countless” might be a more accurate term) vim plugins that present a project drawer in a split window, but even before being spoiled by TextMate those didn’t feel right to me. I’m experimenting with a cocoa tree view that sends files to a specific vim server, and it mostly works, but I’m still not sure it’s the right solution. If I do come up with something, I’ll definitely open it up and share it. (On the other hand, if any of you out there in readerland already know of such a thing, please point me at it!)

So, I’m still reacquaiting myself with all my old muscle memories, but here are some commands I wasn’t previously very familiar with which are proving useful in conquering my TextMate habits:

:e [file]. This is great if you don’t want to use fuzzy finding. Vim will even do tab completion to make things easier.
:ls. Shows all of your buffers.
:buffer [file]. Fantastic for quickly switching between buffers. You can give it just part of a file name and it will jump to the buffer that matches.
The ctrl-6 (technically ctrl-caret) key is awesome for switching back and forth between two buffers. For instance, if I just need to quickly look at one buffer, I can jump right back to where I was with ctrl-caret.
ctrl-W introduces a whole host of options for working with split windows.

And lastly, can I just say that Vim is seriously the poster-child for documentation? I recommend spending 15-30 minutes, every day, in :help, just exploring. There is a LOT there, and all excellently documented.

So, all you vimsters out there: what commands do you frequently use? What features of vim are you so dependent on that you’d be useless without them? Do share!

[from jaz] Is Design Dead?

Fri, 12 Sep 2008 12:59:41 -0700

For many that come briefly into contact with Extreme Programming, it seems that XP calls for the death of software design.

Typed Logic: "Lucky you!"?

Sat, 30 Aug 2008 14:56:11 -0700

"I was lucky to work on 7 paying contracts using declarative languages, because I was the best code-grinder on my current job, I used my LoCh effectively and then wrote about the successes and taught techniques to my peers, all of which luckily attracted the notice of hungry companies needing a competitive advantage."

[from phil1eng] Dreamsongs Essays Downloads

Fri, 15 Aug 2008 11:04:34 -0700

Richard P. Gabriel, Worse is better,

Possible Personal Essay Topics for Term Papers

Wed, 13 Aug 2008 20:21:49 -0700

Sometimes picking out essay prompts and subjects and writing on your own can help prepare you for writing intensive classes. This article has a lot of great ideas for that.

Mike Vanier: opinions

Tue, 22 Jul 2008 04:49:25 -0700

Why functional programming? " Sliding up the banister

Tue, 22 Jul 2008 00:49:55 -0700

yet another "why functional programming"

Essays

Fri, 18 Jul 2008 17:50:32 -0700

The Observation Deck

Mon, 07 Jul 2008 21:48:33 -0700

Editing service

Tue, 01 Jul 2008 05:38:13 -0700

first-class paper redactors provide service here

FOSS Sin: Pointless Duplication of Effort | Fred Trotter

Wed, 25 Jun 2008 12:56:40 -0700

Detailed explanation of why two open source efforts working on the same thing is a pointless duplication of effort, and how to tell the difference between pointless and pointful parallel efforts. Uses FOSS electronic health/medical record software as exa

Eric's Random Writings

Fri, 30 May 2008 22:45:50 -0700

Essays on Geology, History, and People

Sat, 24 May 2008 12:14:36 -0700

Paul Graham

Wed, 21 May 2008 01:16:29 -0700

Open Source and the Benefits of Education

Sun, 18 May 2008 04:13:24 -0700

When duplication is not duplication

Thu, 06 Mar 2008 15:46:06 -0800

I was looking through some C code today, and stumbled across this lovely little gem:

tmp = "\"#";
while (*tmp) {
  FD_SET(*tmp, url_encode_map);
  tmp++;
}

Now, be honest. I don’t care how good you are at C, it takes you a few brain cycles to process that and figure out that it is just setting two bits in a bit field. It really should have been written like this:

12	FD_SET('"', url_encode_map);FD_SET('#', url_encode_map);

This raises the question: why wasn’t it? I’ll tell you why:

Programmers have this burning desire to avoid code duplication. We’re taught, almost since the cradle, to abhor duplicated code and to avoid it all cost. Duplicating code is evil, it leads to unmaintainable code, and propogates bugs. Never, ever, do it!!!

Allow me to let you in on a little secret.

Calling the same function twice is NOT duplicating code. Not if the arguments change between calls.

Even calling the same function three times in a row is kosher. Four times, even. At some point, you might want to consider a loop, if the arguments can be determined functionally, but only do so when the list of similar function calls is harder to read and understand than the loop is. This is often when the loop takes fewer lines of code than the function calls do:

1234	for (i = 127; i < 256; i++) { FD_SET(i, hdr_encode_map); FD_SET(i, url_encode_map);}

There. Had to get that off my chest. Now, back to work.

custom term paper editing

Sun, 10 Feb 2008 12:23:10 -0800

http://customwritingservices.org/custom-term-paper.php

Buy custom writing

Mon, 04 Feb 2008 03:16:36 -0800

http://buy-custom-essay.org/essay-writing.php

research papers topics

Mon, 04 Feb 2008 01:30:27 -0800

http://iresearchpapers.com/how-to-write-a-research-paper.html

Stevey's Home Page - The Emacs Problem

Sat, 02 Feb 2008 23:41:00 -0800

Stevey's Home Page - The Emacs Problem

Sat, 02 Feb 2008 23:37:35 -0800

This I Believe, Inc.

Tue, 15 Jan 2008 07:10:26 -0800

Design Issues for the World Wide Web

Sat, 12 Jan 2008 03:09:06 -0800

Research paper writing

Fri, 21 Dec 2007 00:57:39 -0800

http://custom-paper-writing.com/blog/writing-a-research-paper.html

Never. Ever. Cargo-cult.

Tue, 08 Jan 2008 11:35:58 -0800

I was told today on a mailing list that some people have been justifying their coding decisions by saying things like “but that’s how Jamis does it!”

And I was mortified. Because someday a time will come (and likely already has!) when the things I’ve written will be surpassed by a better way, and I will wilt with embarrassment if anyone uses “that’s how Jamis does it” to justify continuing with the antiquated style.

I’m learning, constantly. Every project I undertake teaches me something new. Every programmer I’ve ever worked with has shown me a better way to do things. “How X does it” (for absolutely any mortal value of X) is a moving target, and if you’re blindly basing your designs on something I (or anyone else) wrote a year or two ago, then you should step cautiously.

Never. Ever. Cargo-cult. If someone writes about something that you find clever, understand why you think it is clever. If someone preaches a better algorithm, understand why the algorithm is better. And if someone asks why you do something a certain way, argue it on it’s own merits, without resorting to an appeal to someone’s (supposed) authority. If you can argue that something is better than something else solely by contrasting it’s pros and cons against the alternative, you’ll be taken much more seriously. And you’ll have a much better chance of recognizing a better way when it is presented to you.

I’ll say it again. Never. Ever. Cargo-cult. Ever.

That said, I’ve been very, very quiet lately, and I apologize. I’ve been rethinking some priorities and experimenting with some new interests. Also, I’ve been trying to finish up (finally) Net::SSH v2 and Net::SFTP v2. Hopefully this year I’ll climb out of the hole I dug for myself last year and have more to blog about again.

Eric's Random Writings

Wed, 02 Jan 2008 08:03:09 -0800

A quasi-comprehensive look at open source in 2007: Part 1 | The Open Road - The Business and Politics of Open Source by Matt Asay - CNET Blogs

Fri, 28 Dec 2007 10:57:11 -0800

Un resumen de los caminos del open-source en 2007-

David A. Wheeler

Fri, 28 Dec 2007 03:55:41 -0800

GPL vs BSD: A Matter of Sustainability

Fri, 21 Dec 2007 11:59:36 -0800

"Both license models make software free, but only GPL software is sustainably free. The BSD gives greater freedom, the GPL gives more freedom. Choose which one you value more."

GPL vs BSD, a matter of sustainability ~ numerodix blog

Mon, 17 Dec 2007 20:54:39 -0800