gnome code assistance

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.

gnome-code-assistance is a project which aims at providing general code assistance services. We split out the language specific parts from the gedit plugin into this new project, while the plugin simply becomes a language agnostic consumer of the services provided by gnome-code-assistance. Using dbus as a transport layer, code assistance can be relatively easily integrated into existing editors, and a reference implementation is provided by gedit-code-assistance. It’s all still in the early stages, but it’s currently functional for gedit at least. For the moment, gnome-code-assistance provides diagnostics for a number of languages, including C, CSS, Go, JavaScript, JSON, Python, Ruby, Shell, Vala and XML. Other services, such as code completion, symbol browsing, cross-referencing and smart indentation are in the works.

gnome-code-assistance diagnostics in gedit

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 (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://
cd gnome-code-assistance && ./ --prefix=$HOME/.local && make install
git clone git://
cd gedit-code-assistance && ./ --prefix=$HOME/.local --enable-local && make install
This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to gnome code assistance

  1. Ole Laursen says:

    You should totally ping emacs-devel and see if anyone’s there is interested.

    • Jesse van den Kieboom says:

      I guess it could be interesting. For now though gnome-code-assistance is built on top of glib and dbus, which I think emacs has an aversion towards. On the other hand, most of the services are written such that, if someone puts in the effort, the transport backend can be relatively easily changed. Initially I actually added a http transport layer, but haven’t maintained it so far.

  2. Stu says:

    This is interesting.

    I’m working on a livecoding tool for gedit, sometimes there are exceptions in the code, and I’d like to underline/highlight the correct lines in gedit – it would be nice if I could use the same code as gnome-code-assistance, but just give it the text of a python exception and have those lines highlighted.

    Any chance of splitting some of the functionality out into a library ?

    • Jesse van den Kieboom says:

      Hi Stu, this is not a use case that we’ve considered yet. I would like to split out gedit independent code in the client (i.e. gedit-code-assistance) into a library in gnome-code-assistance. If that happens, than I think it would serve your use case. This isn’t currently the case, but we’ll keep it in mind.

      The other possibility would be to make your livecoding tool a service in gnome-code-assistance. Then you could implement it there and simply return the ‘live’ diagnostics. Services are tied into gtksourceview languages though, so for this to work you’d have to add your own, python derived, language in gsv, and then create a gnome-code-assistance backend for it. Not sure it’s really the right way to go, but it’s possible.

  3. Pingback: GNOME News: Financial Issues, Mutter-Wayland, West Coast Summit, Community Participation | Techrights

  4. This continues to be awesome! \o/

  5. Constantine says:

    Is it possible to enable Clang’s warnings to see them directly in Gedit? (-Wall flag)

Leave a Reply

Your email address will not be published. Required fields are marked *