The first time I used vi was in the mid-1990s while working on a project that used Aix servers. Coming from a predominately Mainframe background, the power of the Unix command line was new to me, and vi was exotic and exciting. I still have a spiral bound stenographers notebook filled with pages of notes on the often cryptic commands I was using and learning.
In the intervening fifteen years I have continued to use vi on and off, but I have never used it exclusively. There have been any number of other, graphical-based editors to play with, most recently TextMate on Mac OS X.
Last winter I read with great interest Jonathan Snook’s piece on exploring Vim. He rationale for learning Vim was to satisfy the need to learn something new every day. That struck me as a good idea, and learning the modern version of vi, Vim, seemed like a worthy goal. At the very least it would provide many, many opportunities to learn something new everyday.
In the Snook article he linked to a set of screencasts by Derek Wyatt. After watching most of these I was determined to learn Vim.
{{ “059652983X” | amazon_mediumleft_image }}
I started by getting the O’Reilly book
Learning the vi and Vim editors. Reading dense
textbooks is a way to learn something new, but doing is where the real
learning takes place. Using Homebrew I installed MacVim and
started playing around.
Somewhere along the way I discovered the Janus set of plugins, which take alot of the pain of setup away. I happily used this configuration throughout much of the summer. After installing Mac OS X Lion (10.7) I started having problems with my Vim setup, and so I have started over and built a setup for me that works, and that I understand more intimately.
The rest of this posting outlines how I built Vim using Homebrew, describes some of the configurations I’ve made in my .vimrc file, how I’m using git and git submodules to version my setup so I can share it to all my computers, and the list of bundles that I am currently using to extend Vim’s functionality.
While Mac OS X comes with a version of Vim, the compile options for that version did not support everything I wanted. You can view the options by opening a Vim session, and then issuing the :version command. Any option listed with a + is included, those with - signs are not included. The default Vim doesn’t include ruby and it was giving me SegV errors whenever I tried to use it with a Ruby other than the default 1.8.x that Mac OS X comes with.
I resolved the Vim issues by using Homebrew to install MacVim, and by specifying that the Homebrew installed version override the system default version.
brew install macvim --override-system-vimI was careful to run this command while using the Mac OS X default Ruby version. Compiling MacVim with a 1.9.x version of Ruby will fail as not all of MacVim’s dependencies will work with 1.9.x.
Vim is highly configurable, and there are dozens of plugin bundles available to add or alter functionality. Using a ready made bundle set like Janus can save you time and effort. However, in the spirit of learning every day, I opted to create my own .vimrc file.
The excellent Steve Losh article Coming home to Vim was my guide during much of this process. I liberally copied chunks of his .vimrc file, and installed some of the bundles he uses.
Here is my entire .vimrc file.
{% gist 1367558 %}
I’ve noted in the comments at the beginning of the file the various sources I’ve used while building it. The VimCasts.org site is a goldmine of great information, complete with code sample for you to use in your .vimrc file.
It was through one screencast in particular that I was able to cleanly and easily setup a Git repository for my Vim configuration. This repository makes use of Git submodules for the installed bundles, many of which are already Git repositories.
In my case I created a new hidden directory in my home directory called .dotfiles. I then moved my .vimrc file and .vim directory to this new directory. Next I created symlinks in my home directory to point to the actual files in the .dotfile directory.
mkdir .dotfiles
mv ~/.vimrc ~/.dotfiles/vimrc
mv ~/.vim ~/.dotfiles/vim
ln -s ~/.dotfiles/vimrc ~/.vimrc
ln -s ~/.dotfiles/vim ~/.vim Next I created a Git repository in the .dotfiles directory, added a README file, created a cooresponding Github repository, and mated my local repository to the remote on Github.
cd ~/.dotfiles
git init
mvim README.markdown
git add .
git commit -m "initial commit"
git remote add origin git@github.com:zan5shin/dotfiles.git
git push -u origin master You can see the instructions I put inside my README on my dotfile repository on Github.
Once the repository has been pushed to Github it is now simple to use the same configuration on any machine, simply by cloning the repository and adding a couple of symlinks.
Based on advice from Steve Losh and the vimcasts.org screenscast, I am using the pathogen plugin to manage bundles for Vim. This plugin makes it simple to add or remove plugins to you Vim configuration. Since most plugins are already Git repositories themselves, you simply clone the appropriate repository inside your ./vim/bundle directory and you are good to go.
However, since your .vim directory is contained inside a Git repository you should use Git submodules to manage plugins which are themselves Git repositories.
From the root of your Vim configuration repository use git submodule add to clone the plugin repository and add it to the submodule list. For example, here are the steps to add vim-fugitive, a plugin for working with Git.
cd ~/.dotfiles
git submodule add https://github.com/tpope/vim-fugitive.git vim/bundle/fugitive
git commit -m "installed vim-fugitive"
git pushThe screencast on synchronizing with git and pathogen explains these steps beautifully.
Once you have added one or more bundles, committed those changes to you local repository, and push that repository to Github, you are ready to share this new configuration with any other clones you may have created.
The initial clone on a second (or third, or n-th machine) looks like this:
cd ~
git clone http://github.com/username/dotfiles.git .dotfiles
ln -s ~/.dotfiles/vimrc ~/.vimrc
ln -s ~/.dotfiles/vim ~/.vim
cd ~/.dotfiles
git submodule init
git submodule updateThe last two commands above are necessary to initialize and update the submodule repositories. If you only have one bundle installed this seems like extra work, but once you have several bundles installed, the submodule system pays off.
Subsequent updates of a specific bundle goes like this:
cd ~/.dotfiles/vim/bundle/fugitive
git pull origin masterYou can also use the foreach command to update all bundles at once. This is run from the root of your repository, where the .gitmodules file is located.
git submodule foreach git pull origin masterOne caveat to be aware of, as you update plugins via Git you may get messages about the repository tree being dirty. In order to avoid that, following the link at the end of the screencast posting, I added ignore = dirty to each submodule entry in the .gitmodules file as I added plugins.
Here is my .gitmodules file:
[submodule "vim/bundle/fugitive"]
path = vim/bundle/fugitive
url = http://github.com/tpope/vim-fugitive.git
ignore = dirty
[submodule "vim/bundle/solarized"]
path = vim/bundle/solarized
url = git://github.com/altercation/vim-colors-solarized.git
ignore = dirty
[submodule "vim/bundle/gundo"]
path = vim/bundle/gundo
url = https://github.com/sjl/gundo.vim.git
ignore = dirty
[submodule "vim/bundle/nerdtree"]
path = vim/bundle/nerdtree
url = https://github.com/scrooloose/nerdtree.git
ignore = dirty
[submodule "vim/bundle/nerdcommenter"]
path = vim/bundle/nerdcommenter
url = https://github.com/scrooloose/nerdcommenter.git
ignore = dirty
[submodule "vim/bundle/command-t"]
path = vim/bundle/command-t
url = git://git.wincent.com/command-t.git
ignore = dirty
[submodule "vim/bundle/syntastic"]
path = vim/bundle/syntastic
url = https://github.com/scrooloose/syntastic.git
ignore = dirtyThere are many bundles to choose from, and as a rank beginner at Vim, I’ve only scratched the surface. Still, here are the bundles that I’ve incorporated into my setup, along with a brief description of each.
I like humor like this.
A chance encounter and shared moment with one of natures greatest and most fleeting phenomena.
We spent the day in the ER yesterday. Surprisingly this was a good thing.
About 3 am Tuesday morning Sibylle was up with a feeling of nausea and some pain in her upper abdomen. Usually a cap full of Pepto Bismol soothes her stomach and she is fine. The Pepto didn’t work and her pain only got worse. She was able to vomit at least once, but that also didn’t bring any real relief. By 7 am she was feverish, covered in sweat, and in a great deal of pain. I suggested that we go to the emergency room. After a few moments Sibylle agreed.
The intake process at the ER was quick and Sibylle was soon in a bed covered with a heated blanket. The first medicine that was administered was to quell the nausea, and then she was given a shot of Morphine for the pain. The nausea subsided fairly quickly but the pain she was experiencing continued. She said it was up high, just under her sternum, and stretched around her right side, under her rib cage. There was also a second band of pain low in her abdomen, behind and below her belly button.
When the Morphine didn’t work she was given a dosage of Dilaudid through her IV. This is a powerful painkiller and it did the trick. I could see the lines of pain on her face melt away as the drug took hold.
The hospital performed an ultrasound to image her gallbladder and surrounding area. They had already done some palpitations of her abdomen to make sure it wasn’t her appendix. The results of the ultrasound showed some “sludge” in her gallbladder, and some dilation of the bile duct and pancreatic duct. Apparently sludge in the gallbladder isn’t unusual or always cause for alarm. The doctor was more concerned about the duct dilation he was seeing.
The next step was to perform a CT, or “cat”, scan with a contrast agent. Sibylle was given a cup full of what looked like weak lemonade to drink. She said it was delicious - of course this was the only fluid she had been allowed to drink for several hours. During the scan itself she was injected with another contrast agent through her IV port.
The results of the CT scan showed that both ducts, the gallbladder and pancreatic, were within the normal range for size. Also there was no evidence of injury or disease in the gallbladder. No evidence of gall stones or thickening of the bladder walls.
The time for the two procedures, and waiting for their results took until early afternoon. Her nausea was returning, as was the pain. She was given a third shot of anti-nausea medicine (the second had come with the liquid contrast agent as it sometimes gives people nausea), and a final dosage of Dilaudid. The ER attending doctor came in and discussed what they had found, or rather not found. The good news is that there doesn’t appear to be something wrong. The less good news is that we still aren’t sure what is causing her symptoms.
Our next step is to see our primary care physician and schedule an endoscopy. Using a scope the doctor can visually see the lining of her stomach and even, I guess, the upper portion of her intestine. The scope will be combined with a nuclear agent to allow visibility of the gallbladder and the ducts in question.
In the meantime we’ll be having blander food, with smaller portions to try and avoid the miserable experience she had on Tuesday. We have a prescription for both a painkiller and anti-nausea agent in case her symptoms return.
Going to the ER is not any one’s idea of fun, but it was the right thing to do in this case. The staff there was helpful, concerned, and very good about taking care of Sibylle. Just knowing that we weren’t alone was helpful. And seeing her relief as the pain medicine did its job was priceless.
“Once upon a time we soared into the solar system… for a few years… and then we hurried back.”
Inside the mind of the Octopus. This is fascinating stuff.
There are adrenaline junkies and then there are these guys.
It’s noisy at work today. Video taken from my desk of remodeling work currently underway.
Over the past two days I have been trying unsuccessfully to give Apple and Verizon some of my money. You see I want an iPhone 4S, but I am not willing to pay full retail price for one.
As I understand things, your cell phone carrier (Verizon in my case) determines your upgrade eligibility based on a couple of factors: the timeliness in which you pay your bill and the size of your bill. If you have the minimum package and pay late every month you aren’t viewed favorably and likely won’t get any early upgrade option. If you always pay your bill on time, but don’t have the most expensive plan, you’ll get an early upgrade option, but it will only shave a few months off your two-year contract. Four months in my case. Presumably, if you always pay on time and have all the bells and whistles on your plan, then you get an even earlier upgrade date.
February 9th is only 101 days away, which isn’t terribly long in the greater scheme of things, but it would be nice to have a new toy now and avoid the wait.
Yesterday, while on a support call due to a hiccup in my phone’s idea of the correct time, I asked the representative if I could get an early upgrade date. He told me that I would have to go to the store, that they might be able to move me up 30, or even 60 days. 100 plus days isn’t 60, but I thought it was worth a shot. I drove over to the Verizon store in the afternoon to see what they would do for me.
Nothing, as it turns out. According to the sales guy I spoke with, only the store manager can authorize an early upgrade. The store manager only works Monday through Friday, 9 am to 5 pm. Phooey. So this afternoon I left work a few minutes early and returned to the store, this time to see what the manager could do for me.
Nothing, as it turns out. The manager explained the the stores haven’t been able to authorize early upgrades for at least two years. When I tried to explain what I had been told on the phone, he said he doesn’t know why they tell people to go to the store; he isn’t able to give early upgrades.
So I call Verizon back and asked again about an early upgrade. I explained all that I had been through to the representative and he did some quick research at his end. He said that they could do an early upgrade to any of their other phones, but not to the Apple iPhones.
Huh.
He said that Apple “won’t let them”. At first I wanted to believe this was convenient finger pointing, away from Verizon and toward Apple. However, after thinking about it for a few minutes, I think I can understand why. When you are selling hotcakes faster than you can make them, you don’t sell them for $450 off.
All of which means, the only upgrade option available to me is to purchase an iPhone for full retail price, or $649. Spending an extra $450 for 100 days early access is pricy - $4.50 per day. I can wait. Probably not happily, but I can wait.
In the end it is hard for me to stay mad at either Apple or Verizon. They are making a product that I don’t need. I can live without an iPhone. In truth, I could live without a cell phone. That I am willing, along with millions of other people, to shell out $200 or $300 (or more) for a smartphone purchase and sign a two-year contract of $75 or more dollars per month, speaks volumes about the power of marketing and the ability of manufactures to generate desire and demand for their products.
In the meantime, I’ll count the days until February 9th, and at 12:01 am that day I’ll poke the purchase button on Apple’s site and order an iPhone 4S.
Oh wow. Oh wow. Oh wow.