Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Windows support #32

Open
moll opened this issue Aug 23, 2013 · 5 comments
Open

Windows support #32

moll opened this issue Aug 23, 2013 · 5 comments

Comments

@moll
Copy link
Contributor

moll commented Aug 23, 2013

Hey!

A friend of mine, @jarmo, was helping me test Node.vim on Windows and it turns out Vimrunner doesn't run there at all. Let's get it working!

Have you made in progress in this yourself? First off, it seems the pty gem doesn't exist for Windows.
@jarmo
Copy link

jarmo commented Aug 25, 2013

You could use childprocess instead of pty to achieve better cross-platform support.

@AndrewRadev
Copy link
Owner

@jarmo, I tried using the childprocess gem in the childprocess branch. However, as I expected, it didn't work for terminal Vim. I'll expand on that below.

@moll, I haven't worked on that at all. I do have a Windows box that I use exclusively for gaming, but it's not set up to be developer-friendly at all. This is why for this feature I'll mostly rely on your and perhaps @jarmo's work :).

pty is not a gem, it's part of the standard library, but I'm guessing that was just a terminology slip-up on your part. We use it instead of, say, Kernel#spawn, since terminal Vim requires a working terminal (because of it's curses-like interface). A pseudo-terminal works just fine for that purpose. Coincidentally, it also works for GUI Vim, which is why we use it for both cases. ChildProcess does seem like a nice interface, but unless it supports PTYs, I don't think it can be used for Vim.

One option would be to use ChildProcess only for GUI Vim, or perhaps only on Windows machines. Me and @mudge tried to avoid it in the past to simplify code-paths, but it may be time to revisit this. I may be missing something with ChildProcess, though, so if you find out some way to get it working, all the better.

Other potential problems that I see:

  • How do we find the default Vim executable? We could rely on the PATH, but I'm not sure how good of an idea this is. I think Vim for Windows modifies the PATH itself upon installation, and if this is the case, I suppose that's good enough.
  • Should we support terminal Vim? Last I remember, with mingw, you get a POSIX shell, so you can have a working terminal Vim. Not sure if anyone uses it. Also not sure how things work with PowerShell, it was invented after my Windows days. Also not sure how things work with Cygwin. Does Vimrunner work out of the box there?

I'll be somewhat busy in the following weeks, so I'll limit my work to recreational coding and some talk-related stuff. I'll try to pitch into discussions in this thread, however, and provide guidance and experiment testing on Linux.

@jarmo
Copy link

jarmo commented Aug 26, 2013

Maybe @jarib can help you with the problems of ChildProcess. As i've understood then you can do pretty much everything with it and it's cross-platform.

@moll
Copy link
Contributor Author

moll commented Aug 26, 2013

Right, stdlib!

I propose we could depend merely on PATH and let other cases be handled with passing the exe path to Vimrunner.start, just like it does today. As long as the PATH is set up properly and contains a suitable vim executable, everything should work in each of those shell environments. The PTY issue is separate.

LucHermitte added a commit to LucHermitte/vimrunner that referenced this issue Dec 4, 2015
@LucHermitte
Support for native win32 gvim from cygwin ruby
ebc6c4a 
This patch is a first draft toward the resolution of RfC AndrewRadev#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*, ou --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 function 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.

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
@LucHermitte LucHermitte mentioned this issue Dec 4, 2015
Open
@cxw42
Copy link

cxw42 commented Apr 30, 2019 •
edited
Loading

Bump :D . I'm hoping to be able to use vimrunner tests on Appveyor Windows - anyone know if it's possible? Currently, I have the pty issue. Thanks!

@AndrewRadev On Cygwin, vimrunner works fine with the Cygwin X11 and the Cygwin GVim compiled for X11. I do have to manually gvim& before I can run vimrunner, or else it isn't able to start a server (as far as I can tell). So I suppose, to answer my own question, that one workaround might be to use Cygwin on my Appveyor image and try running X headless ;) . Edit However, that wouldn't give me full testing of Windows GVim path handling, for example. (Edit Appveyor has Cygwin installed by default)

@cxw42 cxw42 mentioned this issue May 1, 2019
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@AndrewRadev @moll @jarmo @cxw42