update abbreviations to use Ruby 1.9 hash syntax

[sunaku]

Don't know if you'll want to merge this or not. Maybe keep it in a separate ruby19 branch since Ruby 1.8 hash syntax will live on forever in legacy systems. :(

Cheers.

[tpope]

If you're on Ruby 1.9, surely you're on a Rails new enough to render most of these antiquated? I think I'd rather drop them entirely.

[sunaku]

I don't understand. Even under Rails 3.1.3 and Ruby 1.9.3, these abbreviations are still useful to me. But, as you say, perhaps the real issue is that they don't actually belong in vim-rails?

For example, I only recently learned that these abbreviations come from vim-rails. I had always thought they came with SnipMate. I uninstalled it some months ago and was surprised to find that these abbrevs still worked, so I went in to discover why and learned that they come from vim-rails. :cop:

[tpope]

I mean the most helpful abbreviations in earlier Rails versions (e.g., render :partial =>) have shortcuts in later rails versions (e.g., render). Most of the others were just added for completeness. Of the ones with hashrockets, render :json => is the only one I use more than once a month (by which I mean I render JSON more than once a month, not that I bother with that silly abbreviation). Even if I did use the abbreviation, Is it worth having a 1.8/1.9 debate over render json:?

Other than that, no, I don't object to having abbreviations in rails.vim, but I do object to having a whole abbreviation abstraction. In the past, I looked into leveraging other snippet libraries, but they all seemed hell bent on being exclusively file type based.

[tpope]

Ruby 1.8 is far enough in the past that I'll merge an updated version of this. But I'm even more convinced that most of these are pretty worthless, and may drop them in the next major release.

UltiSnips does enable us to do snippets exclusively in Rails projects, so maybe that's an answer. Note the snippets in the standard pack look just as antiquated as ours.