Philippe Fremy wrote:
> Ali Afshar wrote:
>> On Mar 29, 11:55 am, Philippe Fremy <[EMAIL PROTECTED]> 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.
>>>         Philippe
>> Hi,
>> PIDA 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
>> Vim.
> 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.
Yes your work will certainly help us giving better control. The problem 
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 because you are subscribed to the Google Groups 
"PIDA" group.
 To post to this group, send email to
 To unsubscribe from this group, send email to [EMAIL PROTECTED]
 For more options, visit this group at

Reply via email to