Company Profile

I've been using Bash for years now and have gotten relatively comfortable with the Emacs-based commands necessary to navigate around a previously entered command that needed to be modified. However, I've occasionally encountered cases where I wished that the command line behaved more like vi. Not that I think it's definitively better than Emacs, I just know a bit of vi, and the only Emacs commands I know are the few I've done in some 5-minute tutorial I went through at some point, along with the Bash commands I blogged about in July.

At any rate, my wish apparently came true years ago! Readline, the library that allows you to edit the command line, can be put into vi mode under Bash (and other programs that use Readline). It's easy:

set -o vi

So now you can use the command line pretty much exactly like vi: Esc to get into command mode and use all your favorite vi commands, and the normal commands (i, a, c, etc.) to get back into insert mode and resume typing. If you decide it sucks and want to go back, it's just set -o emacs. Have fun!

Update: I decided it sucks and went back. Maybe you'll like it, though!

Following Thoughtbot's excellent example, I thought I'd also put together a few random vim tips for others who've made the scary jump from Textmate.

Searching

Assuming you've got your fingers dirty with vim's great search functionality (faster to use than Textmate's, I might add), you may encounter occasional unpleasantness when you've just searched for a word or pattern that occurs multiple times throughout a file: too much highlighting (wha?!? is such a thing possible?). It can get annoying if you're trying to skim through the text after you're done with the search and have done whatever you needed to do with the results, especially if there are tons of results and you've searched globally, with something like this:

:%s/ */ /g

For those less familiar, here's what's going on:

• : puts you in ex mode (ex is the line editor that vi and vim are built on top of)
• % designates all lines of the file (1,$ does the same thing)
• s/ */ /g searches for all occurences on each of the designated lines (because of the g, and the % above) of the space character, followed by 0 or more of them (/ */), and replaces those occurences with a single space.
• If you're totally lost, check out a regular expressions primer such as http://www.regular-expressions.info/

At any rate, doing this on most files in vim (assuming your .vimrc file has hlsearch set, as mine does) does the job just fine, but leaves behind a bunch of distracting highlighted space characters. Get rid of them:

:nohlsearch or noh for short.

Your precious search highlighting will be back to normal on the next search. If for some reason you never want search highlighting, you can of course add set nohlsearch in your .vimrc in place of set hlsearch. This highlighting tip is a fairly minor point, but it solved a problem that was really annoying to me for some reason.

Scrolling

It's only been relatively recently that I learned to scroll in vim without moving the cursor. This action is more like the ol' mouse wheel that Textmate users like me knew and loved for "quick" file navigation, only (as with everything else in vim) you don't have to waste time going to the mouse. My favorite version is z., which takes whatever line you're on right to the middle of the screen, where you can view its surrounding context.

Here are some other scrolling actions:

• z- takes the line you're on to the bottom of the screen
• z+ takes the line you're on up to the top of the screen
• Ctrl-y takes the line you're on down one line (so it scrolls the page UP one line)
• Ctrl-e takes the line you're on up one line (so it scrolls the page DOWN one line)

I'm sure my wording is a little weird with these, but it's best if you just practice doing them and see if they are useful. Note that with the latter two commands (Ctrl-y and Ctrl-e), if you try to scroll the page down when your current line is the top line on the page, your current line will move down to become the new top line on the page. This really makes sense; you rarely will want to scroll a line offscreen that you need anyway. If you do, on the other hand, you're probably better off using a split screen (:sp), which is a feature of vim that Textmate definitely lacks, though it's not one I've personally had much use for.

Hopefully some of this will help someone who's looking to get better at vim --- if you're looking for more, I highly suggest the book Learning the vi Editor by Linda Lamb and Arnold Robbins (O'Reilly). Among other things, their tips and examples for searching are outstanding. I assume that the newest edition (now titled Learning the vi and Vim Editors) is even better, though I haven't had a chance to read it yet

As I get more into using Vim and learning all of the keyboard-based commands, I occasionally run across something that doesn't act quite the way I think it should. Case in point: when using the FANTASTIC NERD Tree plugin for Vim (it's a project browser much like Textmate's Project Drawer), I found a (small) bottleneck in my workflow. I like using the H, M, and L commands to quickly navigate to the top ("High"), middle, and bottom ("Low") parts of the screen (gg and G to move to the top and bottom of the buffer are also great).

But NERD Tree overrides H for toggling hidden files on and off (in the NERD Tree browser only; regular files are untouched). I couldn't have this, since my file browser often has lots of folders open (I know it's not ideal, just a hard habit to break). So I plunged into the NERD Tree plugin's source (~/.vim/plugin/NERD_tree.vim) and found the line I needed (around the 120's in my version):

call s:initVariable("g:NERDTreeMapToggleHidden", "H")
needed to change to:
call s:initVariable("g:NERDTreeMapToggleHidden", "I")

I chose I since the NERD Tree browser in not modifiable anyway (the usual use for I is to enter Insert Mode at the start of the line), but that's obviously not necessary. Now I'm navigating to my heart's content (well, to the top of the screen, at any rate).

To answer the obvious question up-front: yes, I'm very aware that Git is hott: proof . In fact, I'm using it to manage my pet soon-to-be-open-source project that I'll announce soon. But we're using Subversion at work, and honestly, I'm a little afraid of trying to migrate a whole company to a new version control system when the current system works fine for most cases and those less technically inclined among us would have a bit of a learning curve.

To make a long story shorter, I am working on a project to add features and integrate new design elements into an existing site, and there are occasional updates that need to get pushed up to the live system. Because of our rotating support schedule, I don't want to commit my changes to the project's trunk: that would chance another developer making a maintenance update and deploying the site (via a Capistrano task). But I obviously need to commit them, so I need a new branch for the project (this is the most common use case that I'm aware of for branches). I'd been under the impression that SVN's branching and merging capabilities were really difficult to use and understand, so I've been putting off learning to do this (and a few times committed the cardinal sin of NOT CHECKING IN).

It wasn't as bad as I thought, even though I was starting off in kind of a weird position: my working copy (of the trunk) had local changes, from where I'd started on the time-consuming updates before realizing I really needed a branch. Here are the steps I took (of course, as with most problems, there are many ways...):

1. Create a branch at the repository, where http://svnrepo.com/path/to/repo is the URL to the repository root:
   svn copy http://svnrepo.com/path/to/repo/trunk http://svnrepo.com/path/to/repo/branches/crazy-new-branch -m "creating crazy new branch"
2. Change the working copy's SVN metadata to refer to the new branch rather than the trunk:
   svn switch http://svnrepo.com/path/to/repo/branches/crazy-new-branch

At this point, I was ready to roll and could svn ci and do other operations as normal, without fear of changes to the trunk.

The next (and final) test was merging those changes back into the trunk, which also ended up working great (I'm not sure to what extent strange problems can arise, but my merges have gone flawlessly so far):

1. Get the revision number where the branch was created (write it down if you are forgetful like me!):
   svn log --stop-on-copy http://svnrepo.com/path/to/repo/branches/crazy-new-branch
   Let's say it was revision number 264.
2. Check out the trunk (in a different location than your working copy of the branch):
   svn co http://svnrepo.com/path/to/repo/trunk projectname_trunk
3. Get into your new working copy of the trunk (the pathname will vary according to where you are in your directory structure, of course):
   cd projectname_trunk
4. Get the trunk's current revision number:
   svn info .
   Let's say it was revision number 286.
5. Merge the branch into your working copy of the trunk:
   svn merge -r 264:HEAD http://svnrepo.com/path/to/repo/branches/crazy-new-branch
6. Fix conflicts as required and push your working copy (of the trunk) back to the repository's trunk:
   svn ci -m "merging crazy new branch changes back into trunk (264:286)
7. Rejoice that things work OK and you don't have to migrate your whole company to a new version control system!

So I recently installed the very interesting Foxmarks add-on (plugin) for Firefox, in the hopes of syncing my bookmarks between my home and work computers. Things worked awesome, with one exception: my beloved Shift-Cmd-F keyboard shortcut for another Firefox extension (the absolutely ESSENTIAL Web Developer Toolbar) was being overwritten with one that opened up my Foxmarks settings.

It's not too hard to change, though: I just needed to edit a file:

sudo vim ~/Library/Application\ Support/Firefox/Profiles/tpatfdag.default/extensions/foxmarks@kei.com/defaults/preferences/prefs.js

The precise location may vary for you, but if you're on a Mac as I am you can just do a locate Firefox and grep through the results until you find what you're looking for.

The offending line was here:

pref("foxmarks.shortcut.OpenSettings", "f");

which I changed to:

pref("foxmarks.shortcut.OpenSettings", "z");

since I don't use Shift-Cmd-Z for anything.

Hope this helps someone!