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 from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
