You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Bug #1752: Namespace clash on Windows ("ruby VIM::command" actually hits "CommandT::VIM::command")

Kind bug
Product Command-T
When Created , updated
Status closed
Reporter anonymous
Tags no tags

Description

On this Windows XP machine running VIM 7.2 and same version of Ruby 1.8.7 as in the Command-T documentation, I see an error like the following on trying to open certain files (but strangely, not all files): 

line 74
NoMethodError: undefined method `command' for CommandT::VIM:Module

And:

Undefined variable s:rubypath
Invalid expression s:rubypath

The error doesn't actually stop Command-T from opening the file, it is just shown in the status line.

After updating to the 1.0 Command-T release the error continues, but now with a little more information shown at the top: 

Error detected while processing C:\Program files\Vim\vim72\ftplugin\ruby.vim

Here is an excerpt from that file around line 74:

if !exists("s:rubypath")
  if has("ruby") && has("win32")
    ruby VIM::command( 'let s:rubypath = "%s"' % ($: + begin; require %q{rubygems}; Gem.all_load_paths.sort.uniq; rescue LoadError; []; end).join(%q{,}) )
    let s:rubypath = '.,' . substitute(s:rubypath, '\%(^\|,\)\.\%(,\|$\)', ',,', '')
  elseif executable("ruby")
    let s:code = "print ($: + begin; require %q{rubygems}; Gem.all_load_paths.sort.uniq; rescue LoadError; []; end).join(%q{,})"
    if &shellxquote == "'"
      let s:rubypath = system('ruby -e "' . s:code . '"')
    else
      let s:rubypath = system("ruby -e '" . s:code . "'")
    endif
    let s:rubypath = '.,' . substitute(s:rubypath, '\%(^\|,\)\.\%(,\|$\)', ',,', '')
  else
    " If we can't call ruby to get its path, just default to using the
    " current directory and the directory of the current file.
    let s:rubypath = ".,,"
  endif
endif

As you can see, the ruby VIM::command call is somehow referencing CommandT::VIM, which seems pretty strange.

The workaround for now is to edit the ftplugin\ruby.vim file to instead explicitly reference the top-level VIM module: 

ruby ::VIM::command(...)

Not sure if this is a common problem when running Command-T on Windows. If it is, it might be worth renaming the CommandT::VIM module to something else to avoid confusion. (It is a shame that this is necessary, as the whole point of putting the VIM extensions inside the CommandT namespace is to avoid this kind of issue.)

Comments

  1. anonymous

    I'm getting the same undefined method error as of 85fd8b0ce657f772ad9c1c50fe502e08ca2bf04c, and I see that the references to the command method have all been prefixed with ::VIM:: as of that revision. This makes even less sense than the original bug report. I'm also on OS X Snow Leopard (stock Ruby 1.8.7), so it's certainly not a Windows thing.

  2. Greg Hurrell

    Funnily enough I can't repro on Mac OS X. If you discover any pattern or underlying cause, do let me know. I'm hesitant to make any changes until I actually understand why this anomalous behavior is occurring.

  3. anonymous

    Had the same issue. I think the problem is that CommandT defines VIM module. As result some plugins, that did not take care to preceed VIM with ::VIM start to fail. I tried to replace CommandT declaration for VIM with XVIM (just to avoid conflicts), and now it works.

  4. Greg Hurrell

    CommandT is defining CommandT::VIM, so as to leave the VIM in the global namespace untouched (::VIM). As this is standard Ruby practice, not really sure why it shouldn't work.

  5. Greg Hurrell

    See also this forum topic.

  6. Greg Hurrell

    As I said, I don't really understand why this is happening, but I think am going to define method_missing on CommandT::VIM and just have it call the missing methods on ::VIM as a workaround.

  7. Greg Hurrell

    Status changed:

    • From: new
    • To: open
  8. anonymous

    this is solved on 30.11 in https://github.com/vim-ruby/vim-ruby/commit/a20098a4844069106c71643ad4f5682707966d85

  9. Greg Hurrell

    As this is essentially a cosmetic issue now, and the fix is upstream, going to mark this one as closed.

  10. Greg Hurrell

    Status changed:

    • From: open
    • To: closed
Add a comment

Comments are now closed for this issue.

Menu