Repository navigation
Windows gVim is displaying "--multiprocessing-fork" error #422
Description
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.
Activity
jrobrien commentedon May 29, 2014
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 commentedon Jun 1, 2014
+1
fopen commentedon Jun 3, 2014
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 commentedon Jun 4, 2014
Same problem: Win7 (64bit), Vim 7.4.
python-modewas installed byVundle.theoden-dd commentedon Jun 5, 2014
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 commentedon Jun 5, 2014
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 commentedon Jun 6, 2014
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 commentedon Oct 31, 2014
same problem in windows 8.1 x64+ gvim 7.4(32bit official version)
dmsul commentedon Nov 29, 2014
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 = 0no matter what. As a result, theRopeContextmethodgenerate_autoimport_cachewas never getting called. Once it was actually getting called, it started throwing the --multiprocess-fork error.My guess is that the
multiprocessing.Processcall 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 = 0should get around the multiprocessing-fork problem without completely shutting rope off viag:pymode_rope = 0.Merge pull request #510 from dmsul/fix-fork-bug
Revert "Remove call to multiprocessing. Fixes issue python-mode#422."
Revert "Remove call to multiprocessing. Fixes issue python-mode#422."
Merge branch 'revert-in-hierarchy' of https://github.com/andrewmwhite…