Win32 support

[idbrii]

I gave it a try and got "Codi does not support Windows yet." Big stacktrace when I try to use it.

Found the code in autoload/codi.vim and tried to modify, but nothing happens in the new split after I :Codi and modify python.

else
  if executable('script')
    function! s:scriptify(bin)
      return 'script -qfec '.shellescape(a:bin, 1).' /dev/null'
    endfunction
  else
    call s:err('Codi does not support Windows without Cygwin yet.')
  endif
endif

I checked my version of script and it seems like that should work:

$ script --version
    script from util-linux 2.25.2

$ script --help
    Usage:
    script [options] [file]

    Options:
    -a, --append            append the output
    -c, --command <command> run command rather than interactive shell
    -e, --return            return exit code of the child process
    -f, --flush             run flush after each write
        --force             use output file even when it is a link
    -q, --quiet             be quiet
    -t, --timing[=<file>]   output timing data to stderr (or to FILE)
    -V, --version           output version information and exit
    -h, --help              display this help and exit

But I've never used script and I'm not sure how it works.

I think we also need this line changed:

let s:magic = "\n\<cr>\<c-z>\<cr>" " to get out of REPL

C-z + CR exits the python repl on Windows, but I don't know if that's consistent across interpreters.

Regardless, all that prevents me from seeing any errors or any functionality (aside from the split appearing).

I'm also not sure how cygwin's script interacts with python (I'm using python3 for Windows from python.org).

Using vim 7.4.1832 from vim/vim-win32-installer.

These seems like a really cool plugin, but I understand Windows support can be tough (and a whole new set of problems).

[idbrii]

I tried forcing sync off and it hangs after :Codi. My guess is because it's not correctly receiving the piped input so script is waiting for input. My vimrun window contains:

C:\WINDOWS\system32\cmd.exe /c (script -qfec ^"python^" /dev/null ^<C:\Users\idbrii\AppData\Local\Temp\VIi41AA.tmp ^>C:\Users\idbrii\AppData\Local\Temp\VIo41AB.tmp 2^>^&1)

I'm not sure how to do the piping properly on Win32. Maybe you have to use type or (with cygwin) cat instead?

[metakirby5]

Hey @idbrii, thanks for providing so much detail about your situation! script is such a finicky command, and I'd really like to switch to using the Python pty module instead, to lessen compatibility issues.

In any case, I'm unable to address Windows support myself (as I lack a Windows machine), but I can give you any information you need if you want to add support yourself and contribute a pull request. It seems like you are using script correctly, so it's probably either magic or piping, like you said.

Codi basically works like this:

• Start a job that invokes script on the bin, which is python in this case
• If asynchronous, grab stdout until the number of prompts received from stdout matches the number of lines in the main buffer; if synchronous, just run the job to conclusion and grab the output
• Get the values associated with each line using the algorithm described here
• Replace the Codi buffer contents

I think a good way to start is to put some form of logging in codi#__callback. I'm a total VimL noob so I just echoerr everything - you probably have a better way though :) And if you do, please share it with me!

[still-dreaming-1]

@metakirby5 As you said, logs are really helpful for debugging complex VimL issues. You can create your own log function that doesn't do anything unless the user defines a log path in their config. You can then safely keep logging calls in your code at points where it is doing interesting things. Here is some code that appends some text to a file on a new line:

let log_path = '/some/path/log.txt'
let log_message= 'hello log'
call writefile([log_message], log_path, 'a')

See :h writefile(). Also, :h function-list will show you a list of all the built in Vim functions listed by category.

[kdurant]

I waited a long time

[metakirby5]

@kdurant Sorry to keep you waiting :( I tried working on the platform-agnostic python-based solution on the pypty branch, but I'm running into some problems getting the output back into vim. Any help is appreciated.

[blayz3r]

Any luck!? plugin looks good

[NewUserHa]

will it come out soon? this plugin looks sexual! is it possible to support gvim as well? thanks!!

[blayz3r]

Can windows be supported via WSL/Bash

[metakirby5]

@blayz3r Possibly - try it and see!

[blayz3r]

So it works in the linux subsytem. I was suggesting calling linux commands using WSL e.g. .

Can this be a viable workaround for Gvim, at least with windows 10

[tngreene]

Hi, this looks super super super cool. Any word?

[tngreene]

Got the right pane to show up with wsl, so, future readers, I think it is possible but a better fix would be just to implement the thing on Windows. I have time... right? Probably not. Sigh. This looks very very useful though! I'm constantly flipping to my interpreter to see what a potential one liner could do for me or seeing which function goes with which module.

[ndavd]

Any updates?

[metakirby5]

Should be working with #158 now, please give it a try!

cc @Jacesheck