Finally, Thanks to AK and Ben. I've been through this topic for a
while, let me explain what I was having in mind:
Basically, I want to use Vim as an UI to my own program, or as many
programs as I can make it. This shouldn't be what Vim stands against I
suppose, for Vim already has built-in support for programs like gdb, I
was just trying to extend it a little. My objective was to send
messages/commands to an external process using key mappings/user
commands, and monitor the output through Vim buffers.
To accomplish this I'd like to use a dedicated thread(preferably a
Python thread) to keep polling from the external process in question.
I had considered using server-client feature, but from my
understanding this far, that would require the external process to
follow Vim's client-server protocol to be able to communicate with
Vim, which most programs out there certainly don't. In contrast, use
polling is much more universal, this way Vim would theoretically be
able to let the user operate any program within its own interface.
Taking Conque as an example -- as an emulator it has to deal with the
user and the Shell process simultaneously -- a typical task for multi-
threading I suppose, but thanks to Vim's single thread-iness (and
probably this bug too), it now has to uses an auto-sequence like this
to make it through:
let s:count= 0
function! s:PollFromShell()
echo 'Counting: ' . s:count " stands for polling in the real code
let s:count= s:count + 1
call feedkeys("\<Right>\<Left>", 't')
endfunction
set updatetime=1000 " once per second
autocmd! CursorHold * call s:PollFromShell()
The real code is much more complicated, this is for showing the key
mechanism.
This works, as Conque has already been used by many, yet it has
serious drawbacks: you see feedkeys() here would interfere with the
user input -- you can't use multi-keystroke commands like 'gt' for the
upcoming 't' could have been flushed away by feedkeys(), neither can
you use any Ex commands any more because they all need multiple key-
strokes. Yet Conque's way to work around this, is to literally map
*every* key on the keyboard(and many others) to its internal function,
which would send them to the Shell process momentarily, only in this
way can it tell the user apart from feedkeys(). Thus the result, no
Vim operations, no commands, just an ordinary(and much slower) Shell
inside a Vim window, that's all.
This is the reason why I think multi-threading would greatly enhance
the ability of Vim. Since Conque has been there for a while with
fairly frequent updating, yet it still use this approach, I suppose
there really isn't any better workaround.
If you have any thoughts please let me know. Now I'm using a less-than-
optimal approach to get around this bug -- I have a second thread
polling the external process but only change the underlying data
structure, it must be careful not to emit any visible output to the
GUI. Meanwhile in the main thread, I have to manually refresh the vim
buffer(through key mappings) to see what happened in the other
program. This is not much of a UI but it seems to be the best I can
get right now.
Thanks
--
You received this message from the "vim_use" 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
