Closed GoogleCodeExporter closed 9 years ago
The --multiprocessing-fork is no argument for vim. Simply remove it. That is no
Vim bug here.
Original comment by chrisbr...@googlemail.com
on 24 Dec 2014 at 12:14
I am sorry but could you, please, clarify. What should I remove?
Original comment by CanisMaj...@gmail.com
on 24 Dec 2014 at 12:33
The --multiprocessing-fork argument. It should be clear by now, that this is
now argument for Vim.
Original comment by chrisbr...@googlemail.com
on 24 Dec 2014 at 12:35
This link might help you.
Embedded python: multiprocessing not working - Stack Overflow
http://stackoverflow.com/questions/15636266/embedded-python-multiprocessing-not-
working
Original comment by yukihiro...@gmail.com
on 24 Dec 2014 at 12:52
I understand. Thank you very much for the help. But still I don't see any way
to wipe out --multiprocessing-fork argument since it is python internal
modifications (it adds this to argv when spawning the process to *distinguish
them*). If vim is an executable for multiprocessing how it will know what to do
(that in some other vim instance I invoked command "py import MyModule;
MyModule.myfunction()") and that this vim instance is just an auxiliary child
process.
Original comment by CanisMaj...@gmail.com
on 24 Dec 2014 at 4:12
I think that since vim is a python interpreter then it must accept
--multiprocessing-fork argument to support multiprocessing spawn method.
Otherwise this function does not work. I think you need to change the status of
the issue.
Original comment by CanisMaj...@gmail.com
on 24 Dec 2014 at 6:50
Vim is not (primarily) a python interpreter. Look at the provided stackoverflow
link. There is nothing we can do about it. Raise an issue with the python
folks, if you like.
Original comment by chrisbr...@googlemail.com
on 24 Dec 2014 at 9:44
And what exactly should I issue there? Because I don't see their fault here.
They constructed their language in such way for some reasons. Vim uses python
as an internal interpreter, but it does not fully comply with python rules.
That is I see the reason.
Original comment by CanisMaj...@gmail.com
on 25 Dec 2014 at 1:19
Ask them how you can avoid, that that particular argument is being used if you
used an embedded python interpreter (that does not understand that particular
--multiprocessing argument)
I think the stackoverflow link provides some useful information. Have you tried
those?
Original comment by chrisbr...@googlemail.com
on 25 Dec 2014 at 1:52
The stackoverflow link wont work for one simple reason. They change executable
to python interpreter and it wont work since it a regular python, not embedded
vim-python, what means there is no vim module there.
I cannot imagine that they say you something helpful, except it is not possible
to do that, because you cannot avoid this argument it is a vital argument for
this kind of process spawning, can you? Either interpreter support this kind of
process spawning or not, I dont see any third possibility here, do you think I
can be done in any other way, or vim does it any other way? Like I said before
how vim going to distinguish processes if I will remove this argument (don't
know if it is possible but still)?
Original comment by CanisMaj...@gmail.com
on 25 Dec 2014 at 3:18
Original issue reported on code.google.com by
CanisMaj...@gmail.com
on 24 Dec 2014 at 10:18