On Fri, May 10, 2013 at 10:54 AM, Jan Pobrislo wrote:
>
> I'm quite curious what is meant by IDE-like features. From my experience
> most of that is covered by plugins already, except for one significant
> roadblock: inability to communicate with external processes without blocking
> whole UI. There are hacks to get around it crudely, but they break other
> stuff.
>
> To allow really complex interactions from vim plugins, one "simple" change
> needs to be done: allow plugins to hook into vim's eventloop. Given
> interface to add and remove filedescriptors being watched with custom
> callbacks and possibly a timeout callback would be all that's needed.


An alternative would be to allow any python thread to call the vim-python
interface through message passing.

Instead of calling directly a python function named 'func' that can only be
run by the vim-thread, a plain python thread could do:

  ret = vim.threadsafe_eval(func)

or, when 'func' has arguments:

  ret = vim.threadsafe_eval(lambda: func(arg1, arg2))

threadsafe_eval() accepts a callable as argument. It puts the callable in a
queue so that the callable may be executed later by the vim-thread and gets
the return value of the callable from another queue (instead of the return
value, the queue may contain the unhandled exception raised by the callable).

This could be implemented with two instances of the python Queue class. The
queues are of size 1 to handle concurrent access to the queues from multiple
threads.

  * The first Queue instance contains the callable:
    The producers are the callers of threadsafe_eval(). threadsafe_eval()
    blocks waiting to put the callable in the queue.

    The consumer is a C function that is called:
      . in all the places where netbeans_parse_messages() is invoked in Vim
      source code. That is: when Vim is idle waiting for characters or when
      Vim runs the sleep command.
      . in ui_breakcheck() so that it will be invoked when Vim does a
      long-lasting job and then checks regularly for <Ctl-C>.

    This C function gets the callable from the queue, instantiates an object
    of the Result class and runs the callable. The return value of the
    callable (or the unhandled exception) is stored in the Result object as
    its 'value' and the Result object is put in the second queue.

  * The second Queue instance contains the Result object:
    threadsafe_eval() blocks waiting for a Result object. If the object
    'value' contains an Exception instance, the exception is re-raised,
    otherwise 'value' is returned.


Xavier

-- 
-- 
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Raspunde prin e-mail lui