Planet CakePHP

I used to make it a part of my day to learn a new tool or find a shortcut for something I already did. It's a habit I got out of for awhile. I called it my laziness: I don't want to spend time operating a tool; I want to spend time building what needs to get built.

In my heyday, I'd have my machine customized to the nines. Lots of shortcuts and gestures and bells and whistles to help me be productive. It was always awkward to hop onto somebody else's machine because I'd instinctively attempt to use a shortcut and it wouldn't be there.
Transitioning
When I switched to a Mac about three years ago, I kept it fairly minimalist. Yes, I had a bunch of new tools to learn. I had settled nicely into using Textmate as my main day-to-day editor. It's a perfectly reasonable editor with lots of great features. I used ProjectPlus, Zen Coding, and a couple other plug-ins. Textmate is a decent application and is easy to get started with. It's like most other text editors: cut, copy, paste with a number of handy options available at the click of a mouse. Expertise in the application grew as I learned a few more of the keyboard shortcuts within Textmate.

However, in my current job, I found my time split between working locally on my machine and needing to be logged into a remote server making to review and test changes. Sure, I could work locally and just copy the files back and forth. And this is exactly what I did. For awhile.
First introduction to Vim
I knew of Vim and would occasionally use it when working on remote servers. Edit an Apache configuration file here. Make a quick change to a file there. I first learned of Vi (of which Vim was born from) back around 1991 when I did a co-op placement and found myself in front of a Unix box.

I learned enough to know how to open a file from the command line (vim filename.ext), edit the file (a to go into insert mode), save it (:w), and then exit (:q). My skill with Vim really hadn't evolved in the 20 years since I first learned of the editor.
Diving in deep
I knew Vim could do more—much more. And so I decided to take the leap and make it my primary editor. I installed MacVim and then watched these great screencasts by Derek Wyatt to get started.

The screencasts are a fantastic place to start because they focus on the core pieces of Vim that you need to know and will quickly pick up steam:

• Movement
• Editing
• Buffers
• Windows

The first three are really the key ones. Movement is important because a lot of the power in Vim is being able to move around a document quickly. Wyatt's screencasts cover the basic movements well. From there, having an understanding of how to get into Insert mode is helpful (beyond hitting a, like I used to do).

Buffers are really where it's at. A buffer is like having a document open in another editor. Except it's just sitting there in memory, waiting to be worked on. By default, you only see one document at a time. I used to have to save, exit out of Vim and then open another file to make changes. This is very tedious. I just didn't know any better. Once you discover how to have multiple files open and to switch between them, you're well on your way to using Vim as your primary editor.

Understanding buffers is just the first step to working with multiple files. The next step is to manage those buffers in a visual way. Two ways to do that include Windows and Tabs.

Tabs are a familiar paradigm. MacVim supports them much like tabs in any other desktop application. Hit Command-T and voila, you have a new tab. That new tab has access to the same list of buffers as all the other tabs. It's just a visual way of separating your work. Terminal-based Vim sessions can also do tabs.

Windows, on the other hand, are different than what you might expect. They're actually more like panes. A screen can be split into multiple panes. They can be split horizontally and vertically and split multiple times.

You might want to check out the NERDTree plug-in which provides a browsable directory view, similar to ProjectPlus. NERDTree uses windows, so an understanding of how windows work will help you more readily use the plug-in.
Diving deeper
Since that time, my knowledge of Vim has continued to increase. I'll take time with a set of features, like tabs and windows, and work with them until they start to become second nature. Then I'll learn a new feature and continue on from there.

After the screencasts, I've gone on to learn how to customize my interface, such as getting a status line that I like. My vimrc file, a file that stores Vim preferences, is getting larger as more and more tweaks go in. It now handles indentation using the approach we have at work (four spaces instead of tabs). These are small things, I know, but I feel like I'm getting back into old habits—good habits: I'm customizing my environment to get the most out of it. As a result, I'm feeling more productive. I feel like I'm getting more out of my tools.

Yesterday, I took time to learn about code-folding (a feature that I, admittedly, have used very infrequently in any editor that I've used). Today, I was told to look into autocomplete, and so I did. Now there is a feature I will use heavily. Going back to plug-ins, I installed Zen Coding for Vim, since I find it quite handy. I mapped a handy keyboard shortcut for it, tweaked some of the snippets, and bam, I'm getting stuff done! I even wrote this blog post in Vim.
All in!
I have undoubtedly become a Vim convert and will likely use it for years to come. Yes, the learning curve is steep but for me, it's been worth it.