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?

Hi, planet GNOME! GSoC on (mainly) GtkSourceView

My blog has just been added to the planet GNOME!

I’m now a GSoC student, working mainly on GtkSourceView (my proposal).

I’m implementing a higher-level asynchronous API for the search and replace. I hope to finish this task in two weeks.
Then: regex search, adapt gedit, modernize the color schemes and ideally GtkTextTag to use CSS.

Search API, some progress

The highlighting of search matches works fine, there was a flickering issue that I fixed.

A property contains the total number of search occurrences. So while the user is typing the text to search, the buffer is scanned to highlight and count the number of matches. What will be really nice is that, once the buffer is entirely scanned, going to the previous/next occurrence will be a O(log n) operation, thanks to gtk_text_iter_forward_to_tag_toggle() (that’s why the matches must be highlighted even if they are not visible on the screen). It was more difficult to implement than always using gtk_text_iter_forward_search() and backward_search() to navigate through the occurrences, but I think it was worth the effort.

If you want to read more details, I’ve written a quite long implementation overview, with the problems to avoid, at the top of gtksourcesearch.c (it will also be useful to future maintainers).

I’ll continue to blog to explain my progress, so stay tuned!

My work on GtkSourceView so far

During the GNOME 3.7 development cycle I’ve been busy working on GtkSourceView, a library used by gedit, Anjuta DevStudio, LaTeXila, and other applications.

The main change is that the completion system has been revamped, mainly under the hood.

Completion: user-visible changes

The only user-visible changes are the bug fixes and the new calltip window sizing, also used for displaying extra pieces of information for proposals. In GtkSourceView 2 there was a function for tuning the calltip sizing, but this function has been removed when porting GtkSourceView to GTK+ 3. Now the sizing works correctly without any tuning function, the window simply fits the natural size of its child widget.

Now the user-comprehensible explanation:


You see that the main completion window is still quite big when there are only a few proposals. For now it’s not possible to change that, but a more compact completion window should be possible in the future.

Completion: developer-visible changes

The completion system is now better documented. A few functions have been deprecated. The code has been simplified (two classes have been almost completely rewritten). There are also some performance improvements, but it was not really an issue previously. Some statistics on the number of lines:


$ wc -l gtksourcecompletion*.{c,h} | tail -1
8012 total


$ wc -l gtksourcecompletion*.{c,h} | tail -1
6728 total

Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Antoine de Saint-Exupéry)

Other enhancements to GtkSourceView

Paolo and I wrote more unit tests, and code coverage support has been added, to have statistics with nice colors.

Lots of compilation warnings have been fixed, especially for the API documentation. For example, the links to GLib or GTK+ symbols work now in the documentation. Compilation warnings are generally easy to fix, it’s a good way to get involved in a project I think, if there are no easy bugs to fix.

That’s all folks. Thanks to Paolo, Ignacio and Jesse for their advices and reviews!

Switch from CMake to Autotools

Last week I’ve migrated the build system of LaTeXila from CMake to the Autotools. Here are the reasons.

The GNU Coding Standards

With CMake, some important make’s targets are missing, for example make uninstall. The main problem is that CMake doesn’t follow the GNU Coding Standards (GCS). The purposes of the GCS, with regard to a build system, is to make a program portable, easy to install, and consistent with the way other softwares are built and installed.

The GCS has several decades of experience, the standards are well established, and we can trust the GNU hackers for having well conceived them. Those that don’t follow them are devoted to reinvent the wheel: they will be faced sooner or later by the same problems already solved by the GCS and the Autotools…

Following standards is important both for users and packagers. If every software uses a different build system, with different options etc, it is a nightmare.

Available macros for GNOME applications

Another reason to use the Autotools, for a GNOME application, is to use the available macros: for the translations (intltool, ITS Tool), the documentation (yelp), the settings (gsettings), …

Creating a tarball

With the Autotools it is as simple as running make distcheck, and putting some files in EXTRA_DIST or prefixing Automake variables with the dist modifier.

It is more complicated with CMake. CPack can be used, but it is far from automatic. When reading the CPack documentation, I changed my mind and wrote a shell script instead.

Learning the Autotools

The Autotools are not as Autopain as people generally say. The learning curve is maybe steeper, but with a good book, there is no reasons to be afraid.

That said, there are certainly problems in LaTeXila, so some tests before the stable release would be more than welcome 😉

LaTeXila: some principles for the user experience

Writing a LaTeX document can be done in different ways. Some people prefer an application like LyX, which hides the LaTeX code and uses sophisticated UIs.

Other people prefer to work directly on the LaTeX code. LaTeXila has chosen this direction. In this context, let’s see, with two examples, some of the principles behind LaTeXila to offer a good user experience.

Inserting a figure

To insert a figure, an application like LibreOffice uses a wizard, so the user can choose an image, its size, the caption, etc.

For a LaTeX application, we could imagine that the corresponding LaTeX code is generated and inserted in the .tex file. Nice, isn’t it?

There is a little problem though: if the user doesn’t understand the code, how does he modify it afterwards to change an option? A good reaction is to look at the documentation to understand what happens. But a quicker solution is perhaps to re-run the wizard and refill the pieces of information and modify the option.

So, to force users to learn LaTeX, LaTeXila avoids wizards!<Esc>dd

A wizard is not a perfect solution. The root of the problem is that looking at the LaTeX documentation can take some time.

A better solution:

  • Good completion of LaTeX commands and their arguments.
  • A way to add easily the required commands for doing common actions like inserting a figure.

The completion works well in LaTeXila, but can be improved. Also, when we are in a command argument, if no completion is available, a calltip is displayed with the prototype of the LaTeX tag:

Calltip showing the prototype of a LaTeX tag

As for the second point, there is a toolbar and menus for common actions. An interesting feature, that doesn’t exist yet in LaTeXila, is the snippets plugin of gedit.

Creating a new document

Creating a new document can also be made via a wizard. We choose:

  • the document type (an article, a report, slides, …)
  • the title
  • the author(s)

But there is the same problem as for figures’ insertion.

In LaTeXila, creating a new document is done via a template. There are some default basic templates, and personal templates can be created.

The user can for example create a big personal template with all the stuff that he could possibly use in a new document. And then, when he creates a new document, he removes or comments what he doesn’t need.

The UI to create a new document has been improved recently ((The window style is different from the GNOME 3 style because I use Xfce, gnome-shell is not supported on my graphics card, and the fallback mode is a bit buggy.)):

New document
Create a new document from a template

To summarize, the idea of LaTeXila is to always deal directly with the LaTeX code, while simplifying as most as possible the writing of this LaTeX code. The users don’t need to be LaTeX gurus, but they should understand what happens.