path is clobbered when opening ruby files about vim-ruby HOT 8 CLOSED

This behavior predates me, but it sort of makes sense. Setting 'path' globally just for Ruby files is a little weird (the default looks like it's for C). So vim-ruby seeds it for you to something sensible, and then you can tweak it with an autocmd FileType ruby afterwards. This is done in rails.vim, for example, to add paths from the current Rails app.

Setting a global path is supported too. Simply let g:ruby_path = "..." and that will be used in lieu of any RubyGems probing. I'm guessing that will address your complaint in practice.

from vim-ruby.

Sure, setting path globally just for ruby seems weird. But for example, I have ruby projects that contain C extensions. I'd like to keep ext on the path so I can find my C files.

It makes sense that vim-ruby would tweak the path for ruby projects, but I don't think it makes sense to clobber the existing settings.

Besides those problems, the current behavior seems less than useful. It adds every version of every installed gem to your path. Maybe trimming to the latest versions would be more useful? Or only adding stdlib?

Even worse, since the path is limited to 1024 characters, this means that very few gems can practically be put on the path. Let's take a look at the path vim-ruby sets for me:

I can use gf, fin, etc for Ruby's stdlib and almost 3 versions of RedCloth.

I'm doing the let g:ruby_path = "..." workaround for now, but I have to reiterate: this feature seems less than useful.

from vim-ruby.

Okay, so let's address the two issues separately. As to adding gems to the path, you're right that not filtering out older gems severely limits the value of this feature (and sometimes older gems sort before newer gems!). And since I've never really found the addition of gems useful, I'm opting for tentatively dropping it rather than fixing it. If people raise a stink, it may come back.

How do you access these C files while working in Ruby? :find something.c? Do you ever gf? If I allow /usr/include to remain in my path, a gf on require 'mysql' now takes me to /usr/include/mysql rather than the mysql.rb in my path. So, this is not a zero cost change.

By the way, that's a 1024 character output limit, not an option limit. :echo &path

from vim-ruby.

Hi @tpope! :-)

Yes, when working with C and Ruby, I typically do :fin whatevs.c. When mixing C and Ruby, I don't use gf to get to C files as I usually have ruby filenames that conflict (e.g. nokogiri.rb and nokogiri.c).

The mysql problem you mention seems like a slight annoyance. Maybe we can prepend to path so that paths vim-ruby sets would be searched first? Though, I would be pretty annoyed if I did gf while working on nokogiri and it jumped me to the installed gem rather than the stuff in lib. What do you think?

from vim-ruby.

Unfortunately the order of the path is irrelevant in this case. Vim does two passes, first looking for exact matches, and only if it doesn't find anything does it try with 'suffixesadd'. On the flip side, this means it's not just C paths that can cause trouble: gf on require 'yaml' takes you to /usr/lib/ruby/1.8/yaml/ rather than /user/lib/ruby/1.8/yaml.rb. AFAICT this can only be mitigated by remapping gf, which is a little too invasive for an ftplugin (but it's what I do in rails.vim).

Side note: one of the reasons I wrote the poorly named rake.vim was to enable adding the current project's lib/ to the beginning of 'path'

from vim-ruby.

Revisiting time! Not a peep has been raised about dropping gems from 'path', and when I went to look at the old implementation, I discovered it was using a soon-to-expire deprecated method. So consider it dead. Forever! My new bundler.vim solves the problem in a much more modern fashion.

Regarding clobbering the global path, it occurs to me there's a very obvious compromise I had not considered. What if we kill the global path if it's the default (.,/usr/include,,), but append to it otherwise? Seems win-win to me.

But while we're slaughtering sacred cows, there's another aspect of the path I want to touch. By default, it includes both the current working directory and the current file's containing directory. Now when I'm in ~/src/myapp and I'm editing lib/foo/bar.rb, I want neither ~/src/myapp nor ~/src/myapp/lib/foo added to my path. But to broaden my frame of reference, does your path deliberately include either of those? Would you miss them?

from vim-ruby.

wrt clobbering the global path: that seems great to me!

The other paths, I don't care about. Really I just want cwd + /lib and cwd + /ext to be in my path so that gf and friends work properly. I don't use the other paths. (This is all outside the context of a Rails app though)

from vim-ruby.

It's done. And against my previous mandate, I have attempted to map gf to prevent that silly directory editing business.

from vim-ruby.