Quite a while back, I introduced gedit code assistance, a plugin for gedit which uses clang to provide various C/C++ code assistance features to gedit such as diagnostics and cross-referencing. The plugin worked reasonably, but there were a few iss
ues that made it difficult to develop it further. First, we couldn’t manage the memory consumption of the plugin very well. Since the plugin works in-process, this meant that gedit memory usages would quickly go up with code assistance enabled. I’m not sure whether we simply forgot to clean up some things (this we could have fixed), or if there were inherent memory leaks in libclang at the time. The only resolution we had was to restart gedit once in a while, which of course is highly undesirable.
The second issue is that we do not really control libclang, so i
f there is any bug that could cause crashes, there is no way we can work around that easily. This is of course true for any library used in gedit, but we found that libclang was not yet as stable as we’d hoped. The third and final issue was really that we couldn’t easily extend the plugin to other languages than those supported by libclang. The reason is that many modern languages nowadays provide parsers, type checkers and other useful code assistance features as part of their standard library, or if third party tools exist, they are also usually written in that particular language. In gedit, we only support C (and by extension Vala) and python as languages in which plugins can be written, so supporting a Ruby parser written in Ruby would have been difficult.
The way forward was fairly obvious, move code assistance out-of-process and make it a service. Doing so solves all of the above problems. Memory can be managed per service, and if it goes wild the service can just be restarted without affecting the editor. Any bugs in a code-assistance service can no longer crash the editor, and services can be written in any language.
The idea is that such code assistance services can be made available to a variety of tools and applications, without the need for each of them to implement their own solution. Nothing is set in stone yet, so it would be great to get input from the people working on IDE’s such as Anjuta and see if we can work towards a single framework for code assistance features, consumable by different editors. If you’re interested, please drop by on #gedit (on gimpnet). For a little bit more information on the internal design of gnome-code-assistance, such as dbus interfaces, have a look at the README.
To try it out, the easiest way currently is to install both gnome-code-assistance and gedit-code-assistance from git, using something like:
git clone git://git.gnome.org/gnome-code-assistance cd gnome-code-assistance && ./autogen.sh --prefix=$HOME/.local && make install
git clone git://git.gnome.org/gedit-code-assistance cd gedit-code-assistance && ./autogen.sh --prefix=$HOME/.local --enable-local && make install