command() hangs with default config on OSX w/MacPorts Vim

[fweep]

I'm using Vimrunner under OSX, and it's hanging on start with vim. I can manually start and interact with a server as expected from the command line. The specs/config I'm using work fine in Linux.

I was able to get it working with MacPorts's mvim, which is just a wrapper around MacVim. Unfortunately, that isn't a headless configuration, so it's not a viable long-term solution.

I've created a gist with config details, including the output of both vim --version and mvim --version. I'd be happy to help test/track this down, but before I dive in there, do you have any ideas? I've already read all of #11, which is how I got this far.

Thanks for the gem! This has really changed how I write plugins.

[AndrewRadev]

Interesting. The Mac situation is a bit odd, since Vim needs X11 bindings for this (for some reason), but technically, I don't think a Mac has an actual X server.

For this particular issue, one likely culprit is --serverlist not working. Vimrunner spawns a Vim, but then waits until vim --serverlist returns the name of the server until it starts working. Then again, that's a bit odd, since there should be a 5-second timeout after which it would break...

For now, could you start a Vimrunner server (for example, by executing the vimrunner command) and try running vim --serverlist in a separate terminal? You should get a name like VIMRUNNER0.somenumbers. One other thing that might be a good idea is to try and start an X11 server manually, but I'm not sure how to do this on a Mac.

Other than that, the configuration seems just fine. You mentioned you can manually start and work with a server. This would mean with something like vim --servername FOO and then vim --remote-edit filename --servername FOO? Does that work fine?

Thanks for the gem! This has really changed how I write plugins.

Thank you for your kind words :). As you can see, it's still somewhat iffy, but we're working on it.

[fweep]

I'm wrong about "start" hanging. Start works fine. I get back a Vimrunner::Client, vim starts up, and the server is listed if I run vim --serverlist in another window.

vim = Vimrunner.star

What hangs is a subsequent command:

vim.command("version")

I've confirmed that Vimrunner is choosing vim (on my system, that's a MacPorts-provided Vim). So it's not a problem with MacVim/mvim. I'm reasonably confident that MacPorts is irrelevant here; it's just building standard Vim 7.3 source, and you can see from the gist (above) that the options are all compiled in. I'll try building my own from source and confirm that if I run out of other ideas.

Using the same vim executable that Vimrunner chooses (confirmed), I can start a server from the command-line via vim --servername foo and send it remote commands:

vim --servername foo --remote-expr "version"

I'm going to re-read that closed issue that referenced PTYs and make sure I've covered that area. At this point my suspicions are pointing in the direction of TTY problems.

I'll rename this issue to reflect that it's command that's hanging, if I can.

[AndrewRadev]

I can't figure out what the problem could be. One thing you could try is run vim.type("key-sequence") and see if the key sequence is executing successfully. Also, try vim.server.remote_expr("1") and see if you get a result. If one of these hangs, then it's a communication problem. If not, it's probably the VimrunnerEvaluateCommandOutput vim function.

[AndrewRadev]

Did you find anything out on this issue?

[fweep]

I never could get it working properly in OSX, and haven't been doing much Vim plugin development recently. I'd like to use it, but unfortunately don't have anything helpful to add.

I did just try it again to check, using Vimrunner 0.3.0 and Vim 7.4.035 (MacPorts). With this basic script, it still just hangs:

#!/usr/bin/env ruby

require "vimrunner"

Vimrunner.start do |vim|
  vim.edit "file.txt"
  vim.insert "Hello"
  vim.write
end

Based on the documentation, that should be running mvim since I'm in OSX (I think it's weird to not default to vim from PATH on every system, but I don't think that's the problem). In my case, that's the MacPorts version in /opt/local/bin/mvim (7.4.035).

I also tried forcing it to use vim:

#!/usr/bin/env ruby

require "vimrunner"

Vimrunner::Server.new("/opt/local/bin/vim").start do |vim|
  vim.edit "file.txt"
  vim.insert "hello"
  vim.write
end

That results in:

/Users/jim/.rvm/gems/ruby-2.0.0-p247@vimrunner/gems/vimrunner-0.3.0/lib/vimrunner/server.rb:37:in `initialize': undefined method `fetch' for "/opt/local/bin/vim":String (NoMethodError)
        from ./foo:5:in `new'
        from ./foo:5:in `<main>'

And finally, I tried forcing it to use the stock OSX Vim (7.3.x) at /usr/bin/vim, and that also gets the traceback above.

If no one else is seeing this in OSX, there may be something related to MacPorts that's causing it. I'm very confident that my MacPorts installation is stable; it works with everything else I use, including a number of complex Vim plugins. I know all the kids these days use Homebrew, so maybe there just aren't any others out there trying to use Vimrunner with MacPorts.

This is actually a new Mac that I just configured recently, so it's not the same one I was using when I first opened the bug. The environment is very similar, but that shows that it's reproducible.

I'd be happy to try something else if you have a suggestion, but I'm not likely to dive into debugging it myself until I have time to actively work on plugins again.

[mudge]

Hi Jim,

There is a mistake in the README re the options to Vimrunner::Server, you now have to pass the path to vim like so:

Vimrunner::Server.new(:executable => "/opt/local/bin/vim")

Re mvim vs vim, @AndrewRadev is right re the messy situation with X11 support in Mac OS X builds of Vim. I believe MacVim has its own custom clientserver implementation that doesn't use X11 at all in order to achieve this functionality.

[AndrewRadev]

Since I can't really debug this issue effectively, and it's been a while, I guess I'll go ahead and close it for the moment.