Windows gVim is displaying "--multiprocessing-fork" error

[fsw0422]

I use gVim as my main text editor for python in Windows

and after some updates, gVim is displaying some errors not shown before.

I'm guessing with the superficial result that,

since Windows is not a POSIX environment, fork is an unknown.

Well, I still wanna use python with gVim and this plugin is far better than any others.

Any suggestions? The full error is as follow.

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 10 2013 14:38:33)
Unknown option argument: "--multiprocessing-fork"
More info with: "vim -h"

Oh, and I'm running Windows 8.1 64bit

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jrobrien]

This just started hitting me on Win7 64bit. Likely after upgrading to Vim 7.4.

I did not dig in far enough to fix the problem but disabling rope support stopped the error.

let g:pymode_rope = 0

[juejung]

+1

[fopen]

Fine! But I'd want have rope (and not to hang myself)! :)
I have the same problem. Win7 32bit, Vim 7.4

PS The same thing with XP SP3.

[10p10110111xxi11p00100100]

Same problem: Win7 (64bit), Vim 7.4. python-mode was installed by Vundle.

[theoden-dd]

Good news, everyone!

The problem is in the pymode plugin. Not in the 7.4 version of Vim.

It happens because Vundle and NeoBundle pull the last commit from repo by default.

So at least commit 20e14aa works nice at my Windows 7 64-bit environment.

With NeoBundle something like this change in vimrc will do the work.

One can do FastForward through last commits, starting from 20e14aa to research which exactly commit breaks things down.

PS: Dear Kirill, please take care about your grateful windows users: don't forget to fix this bug before merging into release. We could send you even more postcards if your address didn't change.

[jrobrien]

Thanks theoden-dd.

EDIT (oops)

I thought it was working using the specific rev but then realized I was on a Linux box. I moved back to a Win7 machine and still had the error popping up. Still leaving rope off for now under Win7.

I'm using vundle for bundle install BTW.

[theoden-dd]

You are welcome, jrobrien.

Just to add: I've tested the proposed solution on my another environment Windows 7 32-bit. Works like a charm with NeoBundle.

So I suppose your problem is concerned with a plugin manager.

[cwmine]

same problem in windows 8.1 x64+ gvim 7.4(32bit official version)

[dmsul]

I've looked at this problem a little bit. It looks like this all started with commit 061bf83 which was merged on May 7. It (correctly) fixed a buggy if statement in rope.py that was effectively setting g:pymode_rope_autoimport = 0 no matter what. As a result, the RopeContext method generate_autoimport_cache was never getting called. Once it was actually getting called, it started throwing the --multiprocess-fork error.

My guess is that the multiprocessing.Process call on line 414 of pymode/rope.py is the culprit, but I'm not familiar with several of the modules involved and don't have any more time right now to put into this.

In the mean time, I don't know much this limits rope's usefulness, but setting g:pymode_rope_autoimport = 0 should get around the multiprocessing-fork problem without completely shutting rope off via g:pymode_rope = 0.