D-Bus in vim, and collaborative editing
Alban Crequy
I would like to have a support for D-Bus [1] in vim, and then be able
to write vim plug-ins that use the vim D-Bus connection to communicate
with external applications. My goal [2] is to be able to control the vim
buffer from other applications to enable collaboration features (as
Gobby does) between different editors (vim, emacs) using the same
D-Bus protocol.
I don't know the vim code, but with help from the #vim IRC channel, I
wrote a vim plug-in in python [3] that fires a D-Bus signal each time
the vim buffer is changed. It seems possible to inform external
applications of each change of the vim buffer.
I want also my plug-in to receive to D-Bus methods, so that external
applications can change the content of the vim buffer. However, I am
unable to do that with my plug-in because of the way the D-Bus
connection is implemented in my plug-in.
The D-Bus connection is an Unix socket. When vim fires a signal from the
plug-in, some data is sent through the socket to the dbus-daemon
process. But to receive D-Bus signal, the socket file descriptor must
be added somehow in the vim main loop in order to call a function to
read on the socket and I have no idea how to do that from a vim plug-in
in Python. It may not be possible to do it from a Python plug-in without
modifying the vim code.
It seems that this "mainloop" problem is not specific to D-Bus but other
projects has the same problem:
- Clewn [4]: GDB support in vim. Clewn is an external program but need
a patch in vim to work.
- Slim-Vim [5]: Vim interface to SLIME, the project is abandoned. It
needed a way to add a socket connection.
- Eclim [6]: Eclipse integration in Vim: Vim instances communicate with
Eclipse through the Eclim interface.
- Vim client-server communication [7]
The problem is, there is a lot of different projects, I don't know where
to start looking :)
Can you explain me the place in the vim code where the main loop is
implemented? Should I look at some of the above projects or other ones?
Thanks for your help,
Alban
[1] http://www.freedesktop.org/wiki/Software/dbus
[2] http://alban.apinc.org/blog/2008/05/11/c
[3] http://people.collabora.co.uk/~alban/d/2008/05/remotecontrol.vim
[4] http://clewn.sourceforge.net/
[5] http://wiki.alu.org/Slim-Vim
[6] http://eclim.sourceforge.net/
[7] http://vimdoc.sourceforge.net/htmldoc/remote.html
Sergey Khorev
Alban,
There is an in-built Netbeans interface in Vim, it works in GVim only.
(See functions netbeans_Xt_connect, netbeans_gtk_connect,
netbeans_w32_connect which set up async socket handler)
I think you could write a bridge between D-Bus and Netbeans interface as
a separate process.
Xavier de Gaye
<alban....@collabora.co.uk> wrote:
> ...
> It seems that this "mainloop" problem is not specific to D-Bus but other
> projects has the same problem:
>
> - Clewn [4]: GDB support in vim. Clewn is an external program but need
> a patch in vim to work.
This is not correct, clewn does not need any patch in vim.
With the netbeans vim interface, you can (a) monitor the buffer
changes and (b) change the buffer content. In pyclewn
(http://pyclewn.sf.net a python implementation of clewn), the
DebuggerVarBuffer class in netbeans.py implements (b).
-- Xavier
Les Chemins de Lokoti -- http://lokoti.alwaysdata.net
Vladimir Marek
[...]
> The D-Bus connection is an Unix socket. When vim fires a signal from the
> plug-in, some data is sent through the socket to the dbus-daemon
> process. But to receive D-Bus signal, the socket file descriptor must
> be added somehow in the vim main loop in order to call a function to
> read on the socket and I have no idea how to do that from a vim plug-in
> in Python. It may not be possible to do it from a Python plug-in without
> modifying the vim code.
I also want to do something similar to what you want. I would like to
write once (if no-one will be faster than me :) ) shell support to vim
(no flame please, it just would be useful for me in some specific cases).
My plan is to use empty (http://empty.sourceforge.net) as a layer above
platform specific pty details. And just make vim listen on file
descriptor and fill vim internal buffer structure with the received
information. On the way out, I would execute external command (empty)
for every line written in the shell buffer.
> It seems that this "mainloop" problem is not specific to D-Bus but other
> projects has the same problem:
For console vim, I think that the proper place might be function
RealWaitForChar, look for SNIFF code. I don't care about gui too much,
at least not at the moment. Hopefully others will be able to help more.
> Can you explain me the place in the vim code where the main loop is
> implemented? Should I look at some of the above projects or other ones?
I know vim code very little, I'm just sharing my thoughts. Hopefully it
will be useful to you.
--
Vlad
Yakov Lerner
The D-Bus connection is an Unix socket. When vim fires a signal from the
Does it require a daemon or something ? That is a burden of additional dependency
that I would not like, personally. Why not use vim-remote mechanism ? It is
event-driven and already built into vim.
If you want to artificially limit your mechanism it to be host-local and
then there are more portable solutions than d-bus
(windows has no d-bus).
Yakov
Philippe Fremy
Hi Alban,
As suggested, you need to look into :help netbeans and at the various
projects that are using the netbeans interface. Don't be mislead by the
name, netbeans interface no longer has anything to do with netbeans.
It's a text protocol over a socket that allows to talk to vim and
receive info from vim.
I am trying to improve the awareness of Vim and the netbeans stuff. For
this, I have started a page, describing various projects (successful or
failed ) of Vim integration and I hope to extend it with more
information about netbeans. It's:
http://www.freehackers.org/VimIntegration
regards,
Philippe
Vladimir Marek
>
> As suggested, you need to look into :help netbeans and at the various
> projects that are using the netbeans interface. Don't be mislead by the
> name, netbeans interface no longer has anything to do with netbeans.
Is it still bound to graphical vim (no textmode) ?
Thanks
--
Vlad
Alban Crequy
"Yakov Lerner" <ile...@gmail.com> a écrit :
> On Sat, May 17, 2008 at 4:45 PM, Alban Crequy
> <alban....@collabora.co.uk> wrote:
>
> >
> > The D-Bus connection is an Unix socket. When vim fires a signal
> > from the
> >
>
> Does it require a daemon or something ?
Although two process can communicate using the D-Bus protocol without a
daemon, the usual way to do it on the desktop is through dbus-daemon
with an Unix socket. Using TCP from a remote host is possible too, but
that's not what I wanted to do.
Application using D-Bus can use libdbus as a build dependency.
> That is a burden of additional dependency
> that I would not like, personally.
Do you mean it should be optional at compilation time with a flag, or
do you mean you would like to have the feature without any additional
dependency?
> Why not use vim-remote mechanism ?
> It is event-driven and already built into vim.
I didn't looked at the vim-remote mechanism yet. But I fear the
protocol is tied to vim. My goal was to have a common protocol used by
several editors (like gedit, kate, vim, emacs).
> If you want to artificially limit your mechanism it to be host-local
I don't want the mechanism to be limited to the local host, but I don't
want to put the network code in the editor. I would prefer to reuse the
network code that handles TCP, XMPP or another backend in other editors
too.
editor <--(D-Bus)--> unnamed software <--(internet)--> ... my contact
where the connection on Internet can be TCP or a Telepathy tube.
> and then there are more portable solutions than d-bus
> (windows has no d-bus).
Windows has winDBus but I never tried it:
http://sourceforge.net/projects/windbus
Telepathy has D-Bus tubes to allow applications to use D-Bus on Jabber
(i.e. not on the same host). OLPC use D-Bus tubes, so an activity can
communicate between your laptop and your contacts' laptops through
Jabber (in this case, dbus-daemon is not used).
--
Alban
Philippe Fremy
Yes it is. Although, for me, only a small subset of the features
provided by Netbeans integration requires GUI. You can not show
breakpoint icons and balloon on text vim, but the other features like
ability to modify text, create buffers and so on could easily be
supported on the text frontend of Vim, using a regular socket for the
communication.
regards,
Philippe
Philippe Fremy
> My goal was to have a common protocol used by
> several editors (like gedit, kate, vim, emacs).
>
Then I think that you are on the wrong list. You should go to xdg.
Similar things have been done for Audio players, notification system on
the cross desktop lists: having a common dbus interface.
KDE already has the abstraction of a text editor, it's called a
texteditor kpart. The implementation is very specific to KDE but the
interface is generic enough that it could be used as basis for a
cross-dekstop editor interface.
There's probably something similar on the Gnome side.
I recently also found a kind of generic editor interface on MacOs X:
http://www.barebones.com/support/develop/odbsuite.shtml
What you want is define a generic editor interface at the dbus level,
then every editor could implement it and be remotely controllable by
DBUS. It could be nice to have that level of unification.
For the specific case of Vim, once you have your dbus interface written,
it should fairly easy to implement it using the netbeans socket protocol
of Vim, without even the need to patch Vim.
cheers,
Philippe
Bram Moolenaar
Alban Crequy wrote:
There are two ways. Netbeans hooks itself into the GUI input. See
src/netbeans.c. The other way is adding something to the select() call.
This is in RealWaitForChar() in os_unix.c. Search for FEAT_MOUSE_GPM to
see an example.
--
You can be stopped by the police for biking over 65 miles per hour.
You are not allowed to walk across a street on your hands.
[real standing laws in Connecticut, United States of America]
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///