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 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
>> 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.

Ali

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"PIDA" group.
 To post to this group, send email to pida@googlegroups.com
 To unsubscribe from this group, send email to [EMAIL PROTECTED]
 For more options, visit this group at 
http://groups.google.com/group/pida?hl=en-GB
-~----------~----~----~----~------~----~------~--~---

Reply via email to