2016-04-27 18:30 GMT+03:00 Jacky Liu <bluegene8...@gmail.com>:
> On Tuesday, April 26, 2016 at 4:29:07 PM UTC+8, Markus Meskanen wrote:
>> While I don't expect Vim to become an easy-to-use text editor for beginners
>> or anything, the current Python support simply isn't enough for a standard
>> coder. Vim doesn't support multiple Python versions, so you have to compile
>> multiple versions of Vim. And every time you update your Python, you must
>> recompile Vim. Other editors simply do Python better.
>>
>>
>> —
>> You are receiving this because you commented.
>> Reply to this email directly or view it on GitHub
>
> -----------------------------------------------------------------
>
> You can have the full power of Python from within your Vim only if Vim and
> Python can run *in the same thread with the same memory space*, this can only
> be achieved by *embedding* Python into Vim, not invoking it.
>
> The dynamic run-time solution you mentioned is awfully slow and inefficient.
> Can you imagine an application's UI starts its back-end as an external
> process and then use a pipe or socket to communicate with it later? Its
> awful. UI and the back-end should be within the same process. Emacs even try
> to do data translation between Python and Elisp with its Pymacs, again, its
> awful, hopeless. Vim should never do that.
Both works well enough in Neovim. Though terminal UI is *now* part of
the same executable (will be different one later), Python communicates
through msgpack over a socket. This thing is obviously slower and in
some cases people need to do optimizations, but most of time this is
good enough. Also there are UIs other then terminal one and they all
use pipes or sockets. Unlike for Python support I did not hear about
problems with UI lags (though maybe because +python users are more
common here then GUI users; on the other side UI authors did not raise
issues regarding communication protocol speed so at least they think
that nothing can be done to speed up, at most they know how to write
their UI without it lagging).
Also this is how most web applications work. UI is in browser. Backend
is on server. And between them you have lots of routers which makes
the whole thing much slower then if UI communicates with Neovim
through msgpack. Still they work, using different hacks for different
situations (from having most of the code on the frontend, only sending
a few commands like “save {big blob}” to the backend once in a while,
to requiring client have his own server with controlled latency).
>
> I suppose Python itself doesn't have good support for multiple versions
> within the same environment, try creating a Py2 list inside Py3. You can
> build a py3-enabled Vim and run py2 as an external process, or vice versa.
> You can have both Vims on your system and choose between them each time
> accordingly, I suppose you won't definitely need one project of yours half in
> Py2 and half in Py3.
Python itself (though not Python, but dynamic library loader,
ld-linux.so) has fine support here. Just distribution maintainers do
not bother compiling Python with --enable-shared, so python2 and
python3 effectively cannot be used together unless you go compile them
yourself.
On Gentoo --enable-shared is used, so no such problems here.
Note though that even if you have +python/dyn and +python3/dyn working
at the same time this does not mean that you can use single PyObject
in both interpreters. In this case :python environment is just as
isolated from :python3 as :lua is. So with vim.bindeval the fastest
way of transferring data is using Vim container objects (lists,
dictionaries, but not partials: last is read-only after creation but
still is a container (using list or dictionary should be faster
though)).
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
