Re: vim gui's / vim api
- Philippe Fremy wrote:
> Ali Afshar wrote:Yes your work will certainly help us giving better control. The problem
>> On Mar 29, 11:55 am, Philippe Fremy <p...@...> wrote:
>>> Caleb Cushing wrote:
>>>> I've noticed most recently the need for a vi(m) environment is several gui's
>>>> as sort of an embedded editor. this is really a several year old problem.
>>>> what I'm wondering is... is there anything vim could do to facillitate/ease
>>>> the implementation of such gui's. I hear rumors of a netbeans protocol (was
>>>> that for the netbeans ide? 'cause that don't work no more) but I'm not sure
>>>> that is what's needed for all the problems. not being a programmer...
>>>> would it be possible in future version (maybe 8.0) for vim to implement an
>>>> api? or perhaps there is another way to get functionality easily embedded
>>>> into just about any editor enviroment needed.
>>> Actually and to my surprise, vim is missing very little to be usable in
>>> connection with an IDE. I plan to propose patches for the parts that
>>> could help further. Those will be very small patches because everything
>>> is already there in vim. No need to wait for 8.0 .
>>> The netbean stuff is really not netbean related but a socket interface
>>> to control vim from a remote program. If that remote program is an IDE,
>>> you have what you want.
>>> My plan is to get a generic python vim-remote-controller as a first
>>> milestone, and then get the same things in other frameworks: gtk, Qt,
>>> MFC, whatever...
>>> I'll keep this list (and yzis list) updated about it.
>> PIDA http://pida.co.uk/ is an IDE which embeds Vim like this (and has
>> since Vim 6). As far as we can tell, Vim is missing nothing to make it
>> usable in this way. It also includes a Python remote controller for
> I checked and the solution is not really generic. Pida uses X atoms to
> communicate with gvim, which won't work in environement where vim does
> not use X (like Windows).
> The vim window embedding is done using a Gtk X socket which is even more
> dependent on X and Gtk. I don't think that such window embedding works
> with Gtk on Windows, nor that it works without Gtk but on another
> toolkit. Qt has in theory something for embedding X windows using the
> socket protocol but last time I checked, it did not work reliably.
> Another aspect is that I want to build a KTextEditor KDE interface,
> which provides many advanced editing services that go beyond the typical
> "open that file", and "where is the cursor ?". This will push the vim
> interface in interesting ways. If it succeeds, it will give really
> strong control on the remote vim.
with the X-based communication is that that is the current Vim remote
procedure protocol on X. Windows uses Com. I am not sure what you would
plan to replace this with. If you plan some kind of socket-based
communication, that would be great.
Embedding is even worse, Xembed on X (as you say) with MDI on Windows
(which I could never get to work). I have no idea how you would hope to
resolve this issue other than write a wrapper that does either one or
the other depending on where it is. I am clueless about OSX. As for Qt,
I seem to remember it working reasonably well for XEmbed, really all you
need to give the thing is an X Window ID, and Vim will jump into it.
Please keep in touch with us while you do this, as I say it would be a
great help to us.
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php