Align parameters of a C function declaration, with lineup-parameters

Renaming a GObject class can involve a lot of manual work. Once the type is renamed, the parameters of the function declarations are no longer aligned. In the following example, GtkSourceSearch has been renamed as GtkSourceSearchContext:

_gtk_source_search_replace_all (GtkSourceSearchContext *search,
                                const gchar     *replace,
                                gint             replace_length)
        /* ... */

It is a GNOME convention to align the parameters, so the code must be fixed:

 _gtk_source_search_replace_all (GtkSourceSearchContext *search,
                                 const gchar            *replace,
                                 gint                    replace_length)
        /* ... */

As programmers, we don’t like doing such a manual work, and even less when we are renaming a big class. Unfortunately, the Indent program doesn’t have an option for that. If you use Vim, there is the Align plugin, that have the \afnc alignment mapping. But it doesn’t align the parameters on the parenthesis.

So I wrote a script! The result is in my gnome-c-utils repository (containing only the lineup-parameters script for the moment).

To detect the parameters, a few regular expressions are used. There are quite a lot of restrictions, but it should work for most GNOME software. To have a perfect script, libclang could be used, but I’ve never used it, so regular expressions was a quicker solution.

The script can be used to convert an entire file, or can be used from a text editor (stdin is read, and the output is written to stdout). I’ve documented how to add a key binding in Vim. So by pressing a single key, the parameters are correctly aligned!

This is just a small step to improve the developer experience in GNOME. But I hope this will be useful for other developers. I dream of a GNOME C IDE that handles the boilerplate (for renaming classes too), that aligns the parameters and the function prototypes in the headers, with auto-completion for signals and properties names, and so on.

Search and replace in gedit and GtkSourceView

My GSoC on GtkSourceView/gedit/… is coming along nicely. Here is a screenshot of the new search in gedit:

New gedit search
New gedit search

The visible new thing is the “298 of 703” in the search entry, that shows the position of the current search match, and the total number of occurrences. This is just the tip of the iceberg, as much of the work has been done under the hood. Ignacio (nacho), my mentor, has improved GdTaggedEntry, and I worked on the new API in GtkSourceView, and adapted gedit to use the new API.

Note: almost all my work has already been merged upstream, but not the new search entry.

Search and replace API in GtkSourceView

The new API in GtkSourceView is available. One thing is missing though: regex search.

Why you should use this API:

  • It is asynchronous, i.e. the user interface is normally not blocked when the GtkTextBuffer is scanned. And the asynchronous overhead is small;
  • The search matches are highlighted;
  • You can get the total number of occurrences and the position of a certain occurrence easily;
  • For each search, the buffer is scanned at most once. Once the search occurrences are found, navigating through them doesn’t require to re-scan the buffer, thanks to gtk_text_iter_forward_to_tag_toggle(). As a result, most operations are really fast;
  • The regex search (still to come) will normally do multi-segment matching, also called incremental matching: when a partial match is returned, we take a bigger segment. No need to waste memory space to retrieve the entire buffer contents.

Nice, isn’t it?

Developing graphical IDEs the UNIX way

Programming on a UNIX environment generally involves the use of command line tools: vim/emacs, git, grep, sed, screen/tmux, and so on. What is really nice about these tools is that they do only one thing, but do it well. Now, what about people not wanting to learn shell commands? And sometimes (sometimes), graphical interfaces are more convenient.

An IDE is an integrated development environment. What people think about this “environment” is generally a bloated program (*cough* eclipse *cough*). But what if the environment is not one big application, but several small programs? The small programs can interact a little together through D-Bus, if needed.

Let’s take a few examples.

Specialized text editors

To have a good user experience, the text editor should be smart enough to know the language used (C, C++, Python, Vala, LaTeX, etc.) and implement features specifically for the language. A few examples:

  • Code completion;
  • Switching between the call of a function to its definition;
  • Have an overview of the file (the list of functions, or the structure of a LaTeX document).

Having only one text editor for several types of tasks (C and LaTeX for instance) is not convenient. It works with vim or emacs, but at the cost of passing lots of time in the configuration files. If a graphical application have thousands of settings, we end up with something worse than eclipse. No, instead, there should be one text editor for each task. And one another general-purpose text editor that don’t include specialized features.

This is not just about settings. With a single text editor for all tasks, the UI must be generic enough for the plugins, but they will always be restrictions. On the other hand, with an independent application, the UI can be exactly what is needed: not too generic nor too restrictive.

The common features between all those specialized text editors can be shared in a library. A project is to make the gedit source code more reusable. It would have been a nice GSoC for me (see this draft proposal for more details), but instead I work on GtkSourceView, which is also nice.


Working on a git repository can be a bit difficult at the beginning. A graphical application that implements the basic features can be useful for some people. But it doesn’t need to be available in the same program as the text editor!

Creating a commit, navigating through the repository history, pull, push, changing branches, … have nothing to do in a text editor, in my opinion. There are some things that can be useful in the text editor though: if there is an integrated file browser, we can mark the modified/added/removed files. And in the margin of the text content, we can mark the modified sections.

Search and replace

The search and replace in a text editor can be limited at one file at a time. The search and replace entries can be shown in the top-right corner of the file, with a little button to show and hide the replace entry.

The search and replace in multiple files is another beast. Integrating it nicely in the text editor is a difficult task. Generally the developer choose a dialog window, because it is the best available option, but it partially hides the file contents…

Why not a small application that do only that? It would roughly select a directory, and search in all files in this directory. The text editor can have a menu item “Advanced search and replace” that would launch the small program with some parameters. The advantage of this small program is that the UI is really better, since it doesn’t have all the text editor features.

When we replace some text, sometimes we want to do small modifications afterwards. But normally, the specialized text editor features would not be needed in the small search and replace application.

The specialized text editors would already have features to edit several files at once. For example, when we change the name of a function, all the calls to the function can be renamed too, and adjusting automatically the indentation of the parameters (should be doable).


The general idea is to have small programs with a clean and simple UI, which don’t require lots of configuration, and that work well together. Ideally, they should Just Work™, like other GNOME applications.