When rbenv is used for managing Ruby installations, just checking for an
executable called "neovim-ruby-host" is not enough. It has to be run as well.
If it does not return 0, then neovim-ruby-host is merely a shim for another Ruby
installation.
$ rbenv versions
2.5.0
* 2.5.1 (set by /Users/mhi/.rbenv/version)
$ rbenv whence neovim-ruby-host
2.5.0
$ which neovim-ruby-host
/Users/mhi/.rbenv/shims/neovim-ruby-host
$ neovim-ruby-host
rbenv: neovim-ruby-host: command not found
The `neovim-ruby-host' command exists in these Ruby versions:
2.5.0
$ echo $?
127
Additionally, the detection logic was moved from provider#ruby#Detect() to
s:detect(), because the former is run in the sandbox which forbids calling
system().
ruby uses batchfiles with 'cmd' extension.
gem creates batchfiles with 'bat' extension.
`gem install rails` does the following in Windows (not Cygwin):
1. Run `gem.cmd install rails` on cmd.exe
2. gem.cmd runs `ruby.exe -x gem install rails`
3. `rails` gem is installed.
`rails.bat` is created in the same directory
where ruby.exe and gem.cmd reside.
neovim-ruby-host is a ruby script.
neovim-node-host is a shell script.
Both don't work in cmd.exe so gem and npm provide batchfile shims.
Return the full path of these shims, cmd.exe knows better what to do with these files.
This allows users who have per-project Ruby versions (e.g. with `rvm`)
to pin to a particular gem installation.
For example: `let g:ruby_host_prog = 'rvm system do neovim-ruby-host'`
The exists('g:loaded_foo') convention is rather common, and may be
relied upon in some cases. It's also very unlikely that a user or plugin
has any reason to set g:loaded_foo to zero, so the principle of least
surprise can be brushed aside here.
https://github.com/neovim/neovim/issues/6107#issuecomment-279532143
