I have always struggled with CSS in vim. Seems like it would be easy to implement compared to auto-complete in other filetypes.

All I really wanted to have was some sort of reminder on what was valid properties and where to put the positional arguments when I am using the shorthand properties.

Today I discovered the two things I needed to fix this. SnipMate and Omnicomplete

SnipMate

I forked the basic SnipMate and added some simple snippets for CSS. If you want to use it, then you can install from my GitHub repo directly

git clone git://github.com/csexton/snipmate.vim.git
cd snipmate.vim
cp -R * ~/.vim

Or you can just grab the css.snippets file and add it to your .vim/snippets directly.

Omnicomplete

This is built in to Vim 7, I just didn’t realize it worked for CSS. a simple crtl-x ctrl-o and it should attempt to complete your word for you. Cool thing is that if you use it after a property before you even start to type you can invoke it to get a list of properties.

If this does not work, should make sure that the omnifunc it set to use the CSS completer:

:set omnifunc=csscomplete#CompleteCSS

Making the CSS Dance

Now that you have both of those installed you can do cool stuff like complete your property values

After typing “border-style: ” I pressed type ctrl-x ctrl-o and get a handy popup complete list.

This was generated by typing “margin:<tab>”. No longer have to go look up which order the parameters go in.

I was getting a bizarre error with Apple’s PackageMaker

% /Developer/usr/bin/packagemaker --filter "\.DS_Store" --root-volume-only --domain system --verbose --no-relocate -l "/" --target 10.5 --id com.codeography.program.pkg --resources build/Release/Package/resources --scripts build/Release/Package/scripts --title "Program Name 2.1.10" --version 2.1.10 --root build/Release/Package/root --out installer.pkg                                                                 
Preverifying root
  Preverifying root
  Checking bundle identifiers
  Checking package configuration
  Checking contents
  Loading contents
  Applying Recommended Permissions
  Checking for ZeroLink
Preverifying Program Name 2.1.10
  Preverifying Program Name 2.1.10
Building root
  Building root
  Copying Scripts
  Copying unreadable files to temporary location
    ERROR: Could not copy unreadable files.
  Renaming package files

After hours of searching I found that I had a vim swap file that wasn’t world readable. And when I change the owner of the files that I need to package to be root, my user no longer had read permissions. Finding this was pretty easy using the find command.

% find . \! -perm -444
installer/config/.Info.plist.swp

Deleted that file and everything worked.

Recently I needed to work with some .json files and notice vim didn’t know how to highlight them. A little baffled I turned to google and discovered json.vim. Installed it, setup the autocommand to reconize .json files as json and was set.

But being stingy about what plugins I load, it dawned on me – vim supports JavaScript, why not just use that for highlighting my json files? doing so was stupid-easy. Just add this line to your .vimrc:

autocmd BufNewFile,BufRead *.json set ft=javascript

Done and done. Got good-enough hihglighting and only added one line of vimscript.

After a tweet about vim status lines by non other than Bryan Lyles I set out to get git and rvm info in vim’s status line. Well, git was easy since I was using Tim Pope’s fugitive plugin:

set statusline+=%{fugitive#statusline()}

But had no such luck with rvm, so I decided to roll my own. And thus we have rvm.vim. Which will report the ruby interperter you are using, the version of that guy and the active gemset (if you have one). It does assume you start vim from the terminal, but what self respecting vim user dosen’t live on the command line all day long?

Installation is easy, just go back to the aforementioned command line and paste this in:

curl http://github.com/csexton/rvm.vim/raw/master/plugin/rvm.vim > ~/.vim/plugin/rvm.vim

Or if you are one of the cool kids and use pathogen you can just clone the repo into your bundle directory:

git clone http://github.com/csexton/rvm.vim.git ~/.vim/bundle

And this will give you a similar status line trick to fugitive:

set statusline+=%{rvm#statusline()}

What good is this hotness with out a screen shot?

If you want your status line to look just like this, this is how to do it:

set statusline=[%n]\ %<%.99f\ %h%w%m%r%y%{exists('g:loaded_fugitive')?fugitive#statusline():''}%{exists('g:loaded_rvm')?rvm#statusline():''}%=%-16(\ %l,%c-%v\ %)%P

What’s on your vim status line?

I had some gems that I only needed for development on my mac, and did not want them to be installed to my Heroku slug. I didn’t want them installed because they would break the deployment.

Everything was fine until I wanted to use autotest with my Rails 3 app that is hosted on Heroku. I got this error when I tried to deploy:

ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
   /usr/ruby1.9.1/bin/ruby extconf.rb
   extconf.rb:19:in `<main>': Only Darwin (Mac OS X) systems are supported (RuntimeError)
   Gem files will remain installed in /disk1/tmp/12479_23567910067960/.bundle/gems/gems/autotest-fsevent-0.2.2 for inspection.

As they call out in their documentation, “Heroku does not specify any groups during bundle installation, so all gems from all groups will be bundled with your application.” I needed to find a way to exclude some libraries from being installed.

Based on a tip from the Heroku mailing list I found that the following worked:

gem "autotest-fsevent" if RUBY_PLATFORM =~ /darwin/

But if I was going to exclude one gem, I figured I could exclude all my development gems, so I wound up doing this:

if RUBY_PLATFORM =~ /darwin/
  group :test do
    gem "rspec-rails", ">= 2.0.0.beta.8"
    gem 'factory_girl', :git => 'git://github.com/thoughtbot/factory_girl.git', :branch => 'rails3'
    gem 'autotest-rails'
    gem 'autotest'
    gem 'autotest-fsevent'
    gem 'autotest-growl'
  end
end

So I made that change, and deployment was still failing. I removed my Gemfile.lock and everything worked.

This presents a complication, which according to Yehuda, “because gems no longer live in your application, we needed a way to snapshot the list of all versions of all gems used at a particular time, to ensure consistent versions across machines and across deployments.”

To work around this I am specifying exact versions of the gems in my Gemfile.

Of course if Heroku added support for bundle install --without test, everything would work just as it should™.

Added Bonus: My compiled slug size went from 19.6MB to 5.1MB.