Support for native win32 gvim from cygwin ruby

[LucHermitte]

This patch is a first draft toward the resolution of RfC #32.

The following modifications were required:

• In vimrc, ~/.vim becomes ~/vimfiles under Windows
• The win32 gvim version won't display anything to the console. Even when
  called with --version, --remote_, or --server_
  All commands need to be send with plain "vim" (the version I have cannot do
  anything else than sending commands to a vim server)
  And the spawn has to be gvim -- don't ask me why
  (of course, both have to be in the PATH)
  Hence the new functions spawn_executable() and windows?()
• When ruby comes from cygwin distribution, and when gvim version is the
  native one, paths need to be fixed with cygpath executable.
  In order to ease its use, I've encapsulated its calls from Client methods, and
  provide some new functions like Client.cd and Platform.fix_path
• I've also added Client.runtime.
• When using feedkeys to :source a script, the call seems to be
  asynchronous.
  Vim doesn't wait and the next command is sent much to early.
  I've changed the call to source to use --remote-send. May be we need a
  special version that simply injects vimrunner_rc.
• When we request to rmdir vim current directory (set with :cd),
  cygwin-ruby Dir.mktmpdir finalizer fails. Vim needs to be set back into a
  neutral directory that we won't try to remove.
• New lines may contain a \r before the \n on windows.

The following issues are still pending:

• The cygwin version of gvim distributed with cygwin package manager doesn't
  support +clientserver.
  As such, I didn't tried this version
• I suspect that start/start_gvim only concern the spawn. In order to
  send remote commands, vim is always enough -- no need for gvim (but I
  don't know regarding mvim)
  It may be possible to simplify the codebase.
• As my ruby version comes from cygwin distribution, I haven't tested native
  win32/64 versions of ruby, nor other shells mingw, ...
• It'd certainly be best to merge vimrunner_rc code into the vimrc. Why two
  files? It causes troubles:
  • feedkeys is used to implement Client.source as Client.command relies
    on a function from vimrunner_rc
• I still have errors I cannot explain with UTF-8. I'm not sure where they
  come from. May be vim-client knows how to solve them.
  https://www.omniref.com/ruby/gems/vim_client-ruby/0.1.0/symbols/VimClient

[AndrewRadev]

It seems like a nice start. Skimming through it, I can definitely see a few areas where I'd like style changes, but for now, I think it's more important for me to get this working on Windows myself and see if I can test it.

I guess it would help if I set up both cygwin Vim and a native Vim, and try to get it running on both. I'll let you know when I do that, and I'll probably suggest some changes / ask some questions in the following days. I haven't made changes in a while, so it'll probably take me some time to re-familiarize myself with the codebase. For starters, I'm almost sure there was a reason for separating vimrunner_rc, but I need to refresh my memory and see why. As I'm thinking about it right now -- probably due to the fact that you can use vimrunner with a running Vim instance, which means you need to inject the special commands in it. The .vimrc can be sourced instead, but there might be things in there that make no sense for a running Vim. Not sure.

I'll get back to you with answers to your questions and some suggestions.

[LucHermitte]

Yes of course. I'm just discovering ruby as I'm patching vimrunner to make it work from cygwin. There are certainly many areas where my patch can be improved.

Regarding the cygwin version of vim, you'll have to compile it yourself.

BTW, I've another (unrelated, I suspect) patch. I'll push a pull-request after we've gone through with this one. td;lr I had to have vim.echo return string(eval(a:expression)) or the catched exception instead of redirecting :echo output.

[mudge]

We might be able to use $/ here which should return the platform-dependent end-of-line character.