I replaced hardcoded paths to stylesheets and scripts, like public/stylesheets/sass, with some fancy path detection.
The detection depends on the corresponding gem being declared in Gemfile/environment.rb, then proceeds to look for files in a list of possible directories (like app/stylesheets, which seems pretty popular), then falls back to retrieving the path from the app itself (slow but sure, and only in rare cases).
Works with Sass, Less, and Coffeescript; I only tested it on Sass since that's what was available.
It's my first experience with vimscript - I tried to be nice. :)
1) Support Sass paths other than public/stylesheets/sass (practically…
… any path will work) 2) add completion for Sass partials to Rstylesheet
Merge branch 'master' of github.com:leonid-shevtsov/vim-rails
added path detection for Less and Coffee (untested tho); improved app…
Merge branch 'master' of git://github.com/tpope/vim-rails
Great idea! For example I have CoffeeScript files inside app/coffeescripts.
How does Rails 3.1 asset handling affect this?
The sheer volume of code in this pull request made me squirm, so I've kind of let it sit.
If you mean that introducing a standard convention for .sass and .coffee locations will deprecate this code - well, I do hope it will.
But in my opinion, existing 3.0 and 2.3 applications won't migrate to sprockets, even if they upgrade to 3.1, so for them the problem of locating the correct path remains.
I've gave the matter more thought, and it looks like the "asset pipeline" makes opening the correct file from Vim a much more complex process.
So, I'll look more into the logic and probably submit another patch. Rails 3.1 will probably make the current asset-related commands useless.
What's the current thinking on this? Now that the asset pipeline has started to catch on, I'd like to simplify a bit, perhaps dropping app/scripts and app/stylesheets (which, if memory serves, weren't supported back when this pull request was introduced).
Also, at this point in time, should we invert the above? Default to app/assets and let a projection handle forcing public?
The problem with sticking new files under app/assets is that we don't know what extension to give them. .js? .js.coffee? .js.coffee.erb? Rails further complicates this with its infuriatingly mushy file name handling, allowing such bastardizations as .coffee and .coffee.erb (and maybe even a naked .erb for all I know). And if that wasn't bad enough, CSS adds both SCSS and Sass to the mix, so we can't just look at what gems are installed.
What does rails generate create? Is it customizable? Can we detect that and use it to guide our default?
Basically, rather than deciding a default based on Rails "conventions" or generators, we let the existing project decide.
Crazy? Or craziest?
@tpope You can of course make your own rails generator; however, I am unsure whether you can customize the built in ones.
I really believe this feature should be: if they input 1 or more file extensions explicitly, then that should be the file name (don't add anything); if they don't then it should default to the core language extension for that particular context. The core extension for a stylesheet being simply .css. The core extension for a view being simply .html. Since these extensions are the "base" extensions for a website, this fallback won't break for a long time. So you have to enter .html.erb if you want the erb... Big deal. It's better than it breaking for the other guy who uses .html.haml.
This method seems like it would take a lot less code than any other route, and yet solve the problem. Would this be difficult to implement?
File creation is now correctly handled based on configured generators. I'm thinking that should address all remaining concerns here.