Had a new idea for gnome-vim yesterday. Presently communication between my component code and the vim instance is limited to sending keystrokes and using the vim client-server functionality to (for example) evaluate a vim expression and receive the result. Quite limited, but, well, gnome-vim started out as a quick hack, because I wanted to use vim with Evo.

Several people have asked why I don't make use the vim-gtk code in gnome-vim. My response has been:

• the vim-gtk toolbars and menus wouldn't "just work" as a bonobo control, because they're just straight gtk. They'd have to be rewritten to use bonobo so that the menus and toolbars can be merged with the container's UI.
• gnome-vim must support multiple instances running simultaneously, and needs to maintain communication with each running vim instance.

However, I was thinking more about this second point, and it seems that this is requirement is just due to the structure that gnome-vim inherited from the gtkhtml control (on which I based my initial code).

If instead of writing a component factory, I could simply supply an executable which implements an interface, and oaf should (I think) fire up an instance of the process for each required component. It would be an out-of-process control, but each process would be running the vim process directly (with corba interface implementations and bonobo stuff added).

This would allow a much tighter integration with vim, which would make it possible to support fancier interfaces. I envision gnome-vim being used with Anjuta: when the user begins to type a function name, gnome-vim pops up a menu with possible completions.

I'd like to move to this structure down the road, but in the meantime I have a maintenance version to release.