It work when jumping the Gem method in Rails project.
However, it does not worker when I try to jump the other Gem method by tag in Gem files.

A tag is listed twice in the project – firstly with the relative path and secondly with the Users/username/... prefix.

I simulated the issue with all other plugins disabled and running only with vim-bundler in my .vimrc. Any ideas what I might be doing wrong?

Error detected while processing QuickFixCmdPost Auto commands for "make":
E488: Trailing characters

I get the error (running :Rake test) when both vim-rails and vim-bundle are installed (pathogen). If I remove vim-bundle, the error disappears.

I seem to mostly notice this with github-based dependencies when I try to merge in some bundle update that has changed the commit ref in the lockfile.

As a simple way to reproduce, here's an arbitrary merge conflict I generated:

Gemfile

source 'https://rubygems.org'
<<<<<<< HEAD
gem 'power_assert', github: 'k-tsj/power_assert'
=======
gem 'power_assert', github: 'k-tsj/power_assert', branch: 'power-assert-friendly-inspection'
>>>>>>> branch

Gemfile.lock

GIT
  remote: https://github.com/k-tsj/power_assert.git
<<<<<<< HEAD
  revision: 49bf25fa5dc6090be70c6057c2e9adb7b27260dd
  specs:
    power_assert (1.1.4dev)
=======
  revision: a68292bcfb94a63872c20a934af9e356ed43e810
  branch: power-assert-friendly-inspection
  specs:
    power_assert (0.1.5dev)
>>>>>>> branch

GEM
  remote: https://rubygems.org/
  specs:

PLATFORMS
  ruby

DEPENDENCIES
  power_assert!

BUNDLED WITH
   1.17.1

Opening either the Gemfile or the Gemfile.lock results in these errors:

"Gemfile" 6L, 203C
Error detected while processing function <SNR>39_buffer_alter_paths[4]..<SNR>39_project_sorted[1]..<SNR>39_project_paths:
line   54:
E716: Key not present in Dictionary: revision[0:11]
E15: Invalid expression: matchstr(source.remote, '.*/\zs.\{-\}\ze\%(\.git\)\=$') . '-' . source.revision[0:11]
Error detected while processing function <SNR>39_ProjectionistDetect[10]..<SNR>39_project_projections_list[1]..<SNR>39_project_paths:
line   54:
E716: Key not present in Dictionary: revision[0:11]
E15: Invalid expression: matchstr(source.remote, '.*/\zs.\{-\}\ze\%(\.git\)\=$') . '-' . source.revision[0:11]
Press ENTER or type command to continue

Bonus: even after pressing ENTER and editing away the merge conflicts, I can't :w the file without getting E13: File exists (add ! to override).

Throwing in a debug echo on the vim-bundler plugin (currently using a996611)...

diff --git a/plugin/bundler.vim b/plugin/bundler.vim
index 23a60c5..59b05d2 100644
--- a/plugin/bundler.vim
+++ b/plugin/bundler.vim
@@ -353,6 +353,7 @@ function! s:project_locked() dict abort
     endfor
     let self._lock_time = time
   endif
+  echo get(self, '_locked', {})
   return get(self, '_locked', {})
 endfunction

...we can see why revision[0:11] would be an error - it doesn't get parsed out in the first place:

{
  'git': [
    {
      'remote': 'https://github.com/k-tsj/power_assert.git',
      'versions': {}
    }
  ],
  'gem': [
    {
      'remote': 'https://rubygems.org/',
      'versions': {}
    }
  ],
  'bundled_with': '1.17.1',
  'path': []
}

So what's the fix? It's probably a fool's errand to parse arbitrary merge conflicts into anything meaningful - garbage in, garbage out. But I'd even be content if gf didn't work on conflicted gems or whatnot. It's just a pain wading through these errors when I'm trying to fix merge conflicts. So maybe there's a way to make this more error-safe?

As of Bundler 1.9, for a number of reasons we've changed the default filenames where your application dependencies are expressed. Also, the old Gemfile and Gemfile.lock files will be deprecated as of Bundler 2.0

As such, we've changed:

• Gemfile to gems.rb
• Gemfile.lock to gems.locked

It would be great if the plugin could start supporting these new files.

My ~/.bundle/config reads as follows:

---
BUNDLE_PATH: 'vendor/bundle'
BUNDLE_DISABLE_SHARED_GEMS: '1'

This contributes ~3 secs to the load time of a ruby file in a Bundler-enabled project.

Performance returns to 'normal' when this config is removed.

:set tags with the config in place also seems to suggest that vim-bundler doesn't support this disabling of shared gems (whether at a global or per project level)

$ bundle config
Settings are listed in order of priority. The top value will be used.

path
Set for the current user (/home/.../.bundle/config): "vendor/bundle"

disable_shared_gems
Set for your local app (/home/.../blah/.bundle/config): "1"
Set for the current user (/home/.../blah/.bundle/config): "1"

Am I missing something in my config for vim-bundler?

Thanks

Because vim-bundler puts the full path to each gem on the tags path and because I have quite a few gems, my 'tags' path is truncated. This prevents using <C-]> effectively to jump to gem source code tags.

Seems like something like this would prevent the 'tags' path from getting truncated:

Set tags to <gem_path>/gems/**1/tags.

For the record, here's my truncated tags option:

 tags=~/chef/cookbooks/secure/.git/ruby.tags,
~/chef/cookbooks/secure/.git/tags,./tags,tags,/usr/local/var/rbenv/versions/1.9.3-p392/
lib/ruby/site_ruby/1.9.1/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/site_ruby/1.9.1/x86_64-darwin12.2.1/tags,/usr/local/v
ar/rbenv/versions/1.9.3-p392/lib/ruby/site_ruby/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/vendor_ruby/1.9.1/tags,/usr/lo
cal/var/rbenv/versions/1.9.3-p392/lib/ruby/vendor_ruby/1.9.1/x86_64-darwin12.2.1/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ru
by/vendor_ruby/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/1.9.1/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/1.
9.1/x86_64-darwin12.2.1/tags,~/chef/knife-spork/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/akami-1.2.0/ta
gs,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/app_conf-0.4.0/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib
/ruby/gems/1.9.1/gems/builder-3.2.0/tags,/usr/local/var/rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9

A gem bundled as

gem 'some_gem', path: '~/some/path/gem'

seem to generate an incorrect path in the following manner /absolute/path/to/current/working/directory/~/some/path/gem/lib.

Rubygems 2.2 can share a local gem repository among ruby versions, i.e. instead of something like ruby/2.1.0/gems, one would just have gems, with compiled extensions kept separately and organized by ABI version.

As a more concrete example, on an older project that was created prior to rubygems 2.2, I have:

$ ls -l .bundle
total 8
-rw-r--r--  1 jacknagel  staff   36 Apr 18 09:44 config
drwxr-xr-x  3 jacknagel  staff  102 Mar 18 16:02 ruby

ls -l .bundle/ruby/2.1.0
total 0
drwxr-xr-x  22 jacknagel  staff   748 Apr 16 13:01 bin
drwxr-xr-x  92 jacknagel  staff  3128 Apr 16 12:04 build_info
drwxr-xr-x   3 jacknagel  staff   102 Apr 16 12:56 bundler
drwxr-xr-x  67 jacknagel  staff  2278 Apr 16 12:56 cache
drwxr-xr-x   2 jacknagel  staff    68 Mar 18 16:03 doc
drwxr-xr-x   3 jacknagel  staff   102 Mar 18 16:03 extensions
drwxr-xr-x  66 jacknagel  staff  2244 Apr 16 12:04 gems
drwxr-xr-x  66 jacknagel  staff  2244 Apr 16 12:04 specifications

on a brand new project with rubygems 2.2 installed, I have:

$ ls -l .bundle
total 8
drwxr-xr-x   7 jacknagel  staff  238 Apr 18 10:02 bin
drwxr-xr-x  10 jacknagel  staff  340 Apr 18 10:02 build_info
drwxr-xr-x  10 jacknagel  staff  340 Apr 18 10:02 cache
-rw-r--r--   1 jacknagel  staff   36 Apr 18 10:02 config
drwxr-xr-x   2 jacknagel  staff   68 Apr 18 10:02 doc
drwxr-xr-x   3 jacknagel  staff  102 Apr 18 10:02 extensions
drwxr-xr-x  10 jacknagel  staff  340 Apr 18 10:02 gems
drwxr-xr-x  10 jacknagel  staff  340 Apr 18 10:02 specifications

This doesn't play nicely with vim-bundler's assumptions about the gem repository layout, and as such 'path' isn't set up correctly, etc.

I created Gist with logs files, vimrc and and my PATH.

https://gist.github.com/807735fb2dd4bd82656b#file-vim-in-rails-dir-log-L97

Problem is because it looks like bundler.vim calling ruby to determine the include PATH.

Is there a way to improve that start up time?

The Gemfile for one of my projects is named Jemfile. This is done as it is a jruby project that runs on heroku and heroku gets messed up with jruby if you have a file named Gemfile. Is there a way either through an env var or a # vim: <something> at the bottom of the file to get the syntax highlighting to work? I like it very much in my other projects and it would be nice to have back in this one.

For engines, the app directory need to be added to the list of paths. Currently only lib is appended and thus making the gf experience incomplete for engines bundled in the Gemfile.

I'm using direnv so gems are installed in .direnv/ruby. This is implemented setting the GEM_HOME environment variable.

With that change, bundle can find the gems (bundle list --paths lists all the files, and the project is working), but vim-bundler cannot find any gem.

Any ideas if that can be fixed?

With a gemfile which uses the new hash sintax I got:

Gemfile syntax error:
/.edge/community/Gemfile:9: syntax error, unexpected ':', expecting $end
gem 'mail_form', github: 'mariochavez/mail_form'

If I change my Gemfile sintax to:

gem 'mail_form', :github => 'mariochavez/mail_form'

And run :Bundle everything works!

When loading gems.rb files, I don't get any syntax highlighting, whereas I do with gems.locked (the filetype is gemfilelock).

I'm on Vim 7.4, using the latest HEAD of vim-bundler and this is my .vimrc.

:set path? returns path=.,/usr/include,,

find user

E345: Can't find file "user" in path

gf user

E345: Can't find file "user" in path

<C-]> works.

Plugin list:

Bundle 'aliva/vim-fish'
Bundle 'altercation/vim-colors-solarized'
Bundle 'bling/vim-airline'
Bundle 'godlygeek/tabular'
Bundle 'groenewege/vim-less'
Bundle 'kana/vim-textobj-user'
Bundle 'kien/ctrlp.vim'
Bundle 'nelstrom/vim-textobj-rubyblock'
Bundle 'rodjek/vim-puppet'
Bundle 'scrooloose/nerdcommenter'
Bundle 'scrooloose/syntastic'
Bundle 'thoughtbot/vim-rspec'
Bundle 'tpope/vim-bundler'
Bundle 'tpope/vim-dispatch'
Bundle 'tpope/vim-endwise'
Bundle 'tpope/vim-fugitive'
Bundle 'tpope/vim-rake'

It would be great to provide a bundle grep command. Bgrep would search on the directories listed on bundle show --paths.

I tried sourcing my vimrc by running :so %

Error detected while processing function <SNR>21_Bundle:
line    5:
E666: compiler not supported: bundler
Press ENTER or type command to continue

Should vim-bundler really behave like this?

Hi @tpope, I am using rbenv as my ruby version manager, and I found a bug that the bundler does not work as expected if I open a ruby file from another directory.

the reproducing steps as below:

1. install rbenv and has at lease two different ruby versions
2. install vim-rbenv and vim-bundler
3. create a temp directory with .ruby-version and Gemfile
4. specify a ruby version that different from the global one in the temp dire
5. open some files from another dir e.g. HOME dir

I think the issue is here, system is called in the cwd, not the correct dir which should consist with the Gemfile.

ubygems.rb is no longer available in Ruby 2.5.0, so this command fails:

https://github.com/tpope/vim-bundler/blob/master/plugin/bundler.vim#L356

ruby -rubygems -e ...

Could you please add support for Ruby 2.5.0?

Could you please support local development of gems as well?

Sometimes I'm working in some gem and I'd like to be able to call :Btabedit name but it seems vim-bundler doesn't support gem declarations with "path" yet.

Thank you very much for your script! I've just discovered it yesterday and I found it to be super awesome! That and the gem-tags gem. I hope you live forever :) Thanks!

Not sure If this is a bug of vim-bundler but I'm getting the following message when I try to execute :Bopen airbrake.

"/Library/Ruby/Gems/1.8/gems/airbrake-3.0.3/" Illegal file name
E344: Can't find directory "NERD_tree_3" in cdpath
E472: Command failed

As you can see I'm also using the NERDTree plugin.

It seems like a recent change in bundler keeps overwriting the BUNDLE_PATH value in .bundle/config with an absolute path, instead of a relative path. I'm using Bundler version 1.15.4 and vim-bundler at 97d5077

This .bundle/config works as expected with vim-bundler:

---
BUNDLE_PATH: "vendor"
BUNDLE_DISABLE_SHARED_GEMS: "true"
BUNDLE_WITHOUT: "production"
BUNDLE_CACHE_ALL: "true"

However, every time bundler is run, the file gets overwritten with the full path to the vendor directory:

---
BUNDLE_PATH: "/Users/rohrer/c/bn/mrclean/vendor"
BUNDLE_DISABLE_SHARED_GEMS: "true"
BUNDLE_WITHOUT: "production"
BUNDLE_CACHE_ALL: "true"

After that change, calling e.g. Bvsplit que gives the errorGem "que" is in bundle but not installed .

If I insert a echo gem_paths at line 376 in plugin/bundler.vim I see ['/Users/rohrer/c/bn/mrclean//Users/rohrer/c/bn/mrclean/vendor/ruby/2.4.0']

I guess self.path should handle absolute paths better, though I'm not sure if that's part of the plugin or built in to vimscript.

I randomly started getting this error whenever I try to open a Ruby file

Error detected while processing function <SNR>35_buffer_alter_paths..<SNR>35_project_gems:
line   15:
E484: Can't open file /var/folders/cg/zwfpx2h14sxdy7qym06td_rc0000gn/T/vEBgKP1/12
Error detected while processing function <SNR>35_buffer_alter_paths:
line    2:
E715: Dictionary required
E686: Argument of sort() must be a List

I can't really provide any more specifis, since I didn't really change anything in my VIM config.

By using RVM, GEM_PATH is changed only when cd-ing into the project directory. When using a vim instance opened from outside that project directory, GEM_PATH won't match the project's one.

The only way I see to fix this is to somehow add support for rvm, recognizing the presence of .rvmrc files.

Hello, I've updated this plugin from 72d5dd2 to 7372295. After this vim autocomplete by Ctrl+p has become slower since it scans all gems that in my Gemfile.lock I guess.

Execution of Ctrl+p takes me about 30seconds on the project https://github.com/rails/rails

It seems that if I set BUNDLE_PATH to .bundle vim-bundler thinks that the gems have not been installed, while if I use vendor it works without issues. bundle check shows that the gems are installed properly in both cases.

This is not a huge issue for me as I will just use vendor for this project - but is it a known limitation? If so I'd be happy to document it - if not I'd be happy to troubleshoot further.

vim-bundler version: 37096db

% ruby --version
ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-darwin14.0]

% bundle --version
Bundler version 1.7.4

% vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 25 2014 11:09:31)
MacOS X (unix) version
Included patches: 1-430
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         -gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      -lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -F/usr/local/Frameworks -DMACOS_X_UNIX  -Os -w -pipe -march=native -mmacosx-version-min=10.10 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: /usr/bin/clang   -L. -L/usr/local/lib -L/usr/local/lib -F/usr/local/Frameworks -Wl,-headerpad_max_install_names -o vim        -lm  -lncurses -liconv -framework Cocoa   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -framework Python   -lruby.2.0.0 -lobjc

I'm not sure if this is by design (hopefully not!) because it actually does more, but after e838867, Vim's startup and Ruby file opening went from ~300ms to 1400ms.

I've got a godly scientific benchmark to present:

# Before e838867:
% time vim ~/Documents/monday/app/config/application.rb -c :quit
vim ~/Documents/monday/app/config/application.rb -c :quit  0.22s user 0.04s system 85% cpu 0.303 total
# After e838867:
% time vim ~/Documents/monday/app/config/application.rb -c :quit
vim ~/Documents/monday/app/config/application.rb -c :quit  1.17s user 0.15s system 95% cpu 1.394 total

Hi,

I get this error when trying to do anything with the :Bundle or :Bopen commands:

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/dependency.rb:52:in `initialize': Valid types are [:development, :runtime], not nil (ArgumentError)

bundle works fine from the command line. Bopen does not work due to the error while Bundle seems to get it at the end. Additionally, my tags does not seem to have change the slightest.

Any ideas about what can cause this? Is it one of my gems that has an invalid specification or something?

MacVim seem to be using system ruby, but I'm always using RVM so I'm somewhat sure this could be it. Any idea of how to combine the two?

I can however % bundle open from the command line. I wonder if there is a mismatch in how bundler.vim parses the lockfile to get the gems to how bundler itself does it.

Example:

:Bundle open redis
Gem "redis" is in bundle but not installed

While it does show up in bundle list.

% bundle list | grep redis
  * fakeredis (0.8.0)
  * redis (4.8.0)
  * redis-gcra (0.5.0)

In larger ruby projects, vim-bundler increases vim startup time to several seconds.
After bisecting my .vimrc I found the vim-bundler plugin to be the culprit.

Bundler version 1.6.2

$ rbenv version
2.0.0-p247 (set by RBENV_VERSION environment variable)

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 25 2014 15:27:10)
MacOS X (unix) version
Included patches: 1-430
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         -gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      -lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -F/usr/local/Frameworks -DMACOS_X_UNIX  -Os -w -pipe -march=native -mmacosx-version-min=10.9 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: /usr/bin/clang   -L. -L/Users/jottr/.rbenv/versions/2.0.0-p247/lib  -fstack-protector -L/usr/local/lib -L/usr/local/lib -F/usr/local/Frameworks -Wl,-headerpad_max_install_names -o vim        -lm  -lncurses -liconv -framework Cocoa   -fstack-protector -L/usr/local/lib  -L/System/Library/Perl/5.16/darwin-thread-multi-2level/CORE -lperl -framework Python   -lruby-static -lobjc -L/Users/jottr/.rbenv/versions/2.0.0-p247/lib   

cd to my rails project dir
then just open vim (vim command)
:help bundler

said: Error detected function 22_BufAddHandler[8]...22_AutoUpdate[35]...22_StartExplorer : ligne 81
"bundler.txt" 76L, 3267C

:Bopen doesn't do anything (unrecognized command)

installed in ~/.vim/plugins/vim-bundler/ directory from your git package with Vim-Plug Vim plugin manager.

If now i open a file who is inside this rails project, then use a bundler-vim command, error appears again, but command is recognized and Gemfile open in a new tab.

In an empty directory, vim Gemfile add gem 'sinatra', save, :e config.ru. Got this

Error detected while processing function <SNR>38_buffer_alter_paths..<SNR>38_project_gems: line 19: E716: Key not present in Dictionary: _gems E15: Invalid expression: self._gems Error detected while processing function <SNR>38_buffer_alter_paths: line 2: E715: Dictionary required E686: Argument of sort() must be a List

Same thing after exit and editing Gemfile or config.ru.

Bundler configuration can be made global by placing it in ~/.bundle/config. From what I can see, this file isn't honoured by vim-bundler and it fails to find the BUNDLE_PATH within, so it can't locate where the gems are saved. Installing with bundle install --path=whatever adds the line to the local .bundle/config and works as expected.

After I've updated to neovim 0.8.0 I started to get this error:

Didn't dig too much into the code but here's the error I'm getting. I think it's because dir is not yet declared on line 241

Also worth noting, this only happened on a non-rails ruby project that uses rake.vim: http://github.com/therubymug/keymaker

hth.

Error detected while processing function <SNR>33_buffer_alter_paths..<SNR>33_project_gems:
line   43:
E121: Undefined variable: dir
E15: Invalid expression: dir
Error detected while processing function <SNR>33_buffer_alter_paths:
line    2:
E715: Dictionary required
E686: Argument of sort() must be a List

I'm not sure if this fixable, but on a project I'm working on with ~100 gems in Gemfile, vim-bundler adds about 7 seconds of wait time when loading the first ruby file in the project.

I'm guessing this is due to parsing the Gemfile for all the gem locations to add their tags files to the current ctag path. I don't suppose there's a way to suppress this part until needed, and/or do it in a non-blocking way...

Could you please document in the help for Bedit that with no arguments Gemfile.lock is opened.

Please note, with no arguments, edits Gemfile.lock.

TL;DR: Is it possible for vim-bundler to look in for the Gemfile in :pwd, rather than relative to the currently opened project?

I open my project in Vim. Then I :find rails. And then I try to gf under active_support, but I can't. When I look at Vim's path, I see that my gems aren't there anymore. I assume that's because vim-bundler looks for the Gemfile relative to the currently opened project (Railties, in this case). And the railties gem, like most others, doesn't include their Gemfile in the installed gem, so I can't :find ActiveSupport.

Could vim-bundler look for the Gemfile in :pwd, which is always equal to the working directory?

I've been seeing these weird characters on vim startup that remain on the screen until I do a CTRL-L:

^[[?12;4$y

I've been able to narrow it down to loading the latest vim-projectionist with the latest vim-bundler using vim-plugged. I've removed all the other plugins, and these characters only show up if bundler and projectionist are loaded together -- remove either plugin and they disappear.

I'm running the latest vim compiled by Homebrew:

VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Sep 15 2022 18:56:17)
macOS version - x86_64
Included patches: 1-472
Compiled by Homebrew

I have previously used this plugin with macvim, and have been working to migrate over to nvim. I'm using packer.nvim as a package manager, ie:

return require("packer").startup(function(use)
 use("tpope/vim-bundler")
)

I'm able to use the commands defined, ie :Bopen, :Bedit, etc. However, I'm not getting the syntax highlighting in Gemfile.lock or the keywords in Gemfile, nor does gf work in those files.

I'm able to copy & paste the syntax from bundler.vim into after/gemfile.lock and set a custom augroup for them:

 vim.api.nvim_command([[
    augroup mybundler_lock
        autocmd BufNewFile,BufRead [Gg]emfile.lock setf gemfilelock
    augroup END
 ]])

I haven't been able to track down why it wouldn't have been working before. I've been able to confirm that :verbose autocmd has the augroups from bundler.vim.

In my project dir I have .ruby-version and .ruby-gemset
Bundler is not aware of the project gemset. If I run :Bundle it will install the gems in the default gemset.

I'm using vim 7.4, vim-rbenv, and the latest vim-bundler code, and I'm having trouble with :Bopen <GEM_NAME>. :Bundle works for me as expected but :Bopen is returning the error "Gem <GEM_NAME> is in bundle but not installed". Also in my Gemfile.lock all ruby gems are highlighted as not being installed. Heres the output of two commands run from within vim:

 !ruby -rubygems -e "print Gem.path.join(';')"
/Users/tylernm/.gem/ruby/2.3.0;/Users/tylernm/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0

:!ruby -rrbconfig -e "print RbConfig::CONFIG[\"ruby_version\"]"
2.3.0

which is the exact same output as on my command line shell (zsh). All this seems to point to a gem_path issue. Do you have any tips on how to debug this further? Unfortunately I'm very new to vimscript. Thanks.

Hi quick question,

When I gf in a bundled gem, and I want to gf into a dependency to that gem I cannot get there. I know there must be something that I'm missing, but don't know what I need. Basically vim-bundle correctly changes the path when it goes to the bundled gem, but at that point I don't have all gems paths that I originally had. Is there a way to keep the paths, instead of clearing them, or is there a command to automatically add all the gems in a gem dir when I'm in one?

for example

gf in a file in my project
goes to sinatra/base in gem sinatra
in there I gf on line "include Rack::Utils"

and get "Can't find file Rack/Utils.rb"

My paths are now (which doesn't include any gems):
path=~/.rbenv/versions/2.0.0-p353/lib/ruby/site_ruby/2.0.0,
~/.rbenv/versions/2.0.0-p353/lib/ruby/site_ruby/2.0.0/x86_64-darwin13.0.1,
~/.rbenv/versions/2.0.0-p353/lib/ruby/site_ruby,
~/.rbenv/versions/2.0.0-p353/lib/ruby/vendor_ruby/2.0.0,
~/.rbenv/versions/2.0.0-p353/lib/ruby/vendor_ruby/2.0.0/x86_64-darwin13.0.1,
~/.rbenv/versions/2.0.0-p353/lib/ruby/vendor_ruby,
~/.rbenv/versions/2.0.0-p353/lib/ruby/2.0.0,
~/.rbenv/versions/2.0.0-p353/lib/ruby/2.0.0/x86_64-darwin13.0.1

I've found out that your latest changes introduced a bug where calling e.g.

:Bedit rails

returned a message saying it couldnot find the gem 'rails'

When I reverted to commit ecfb0a2 I can succesfully do the same command.

Steps to reproduce:

• just generate a simple rails app

rails new bundler_test

• fire up vi with the vim-bundler plugin enabled
• Try to open the rails gem

:Bedit rails

When I execute the following in vim

:echo bundler#buffer().project().gems()

the following is returned when I use vim-bundler HEAD

{'action_mailer': '/Users/cvp/.rbenv/versions/fast-require/lib/ruby/gems/1.9.1/gems/actionmailer-3.2.9'}

You can find my .vim dir here: https://github.com/khelben/vimfiles
It is just pathogen controlled set of vim plugins

Given a Gemfile with

gem 'foreman'

When I press gf having my cursor at the f of foreman it gives me an empty view. Running gf a second time yields a tree listing view of the current gem.

This behavior seem to be due to the gem not defining a {gem_name}.rb file in the gem root.