UPDATE: if libpeas1 gets ported to the latest version of GIRepository, then it would be possible to re-enable the Python support in gedit. But only for third-party plugins. That way we keep the best of both worlds. The plugins shipped by gedit itself (the "official" plugins) will be written only in C, but Rust would be welcome too if someone figures out how to write a libpeas-based plugin in Rust. For most users this means that some official plugins will be missing. For third-party plugin developers, this means that a full rewrite of the plugin would not be necessary. Here is the GitLab issue where this is discussed.
The first *.py file in the
gedit repository was added in
2005, 20 years ago.
Since then, it seems that it has always been possible to write gedit plugins
in Python. Well, this is no more.
It deserves some explanation.
Reducing the number of programming languages to deal with
A multi-language project is much harder to manage. Now gedit only uses C and a little of Objective-C for the macOS support. The libgedit-* are entirely written in C.
There was a Vala plugin (Find in Files) but has been removed in 2022 (unfortunately there is no replacement). The commit message already mentions the difficulty of working with multiple languages. So the problem is not new.
Other reasons
Making it easier to package gedit on Windows, avoiding the need to bundle a whole Python interpreter with the app. This also makes the package smaller and the app launches more quickly (better performances).
There are also some inherent difficulties to maintain large Python codebases in the long run. gedit plugins are not specifically large, but still, the difficulties were present. (If Python is your thing, you may have a different experience and opinion. That's fine, there needs to be something for everybody).
So over the recent years a few plugins have been rewritten from Python to C already. With the final goal of phasing out the Python support. This was a slow process, until ...
Some PyGObject and GIRepository updates later
GNOME 48 released in March comes with an update that basically makes all Python plugins unusable in gedit. It's more related to the code dealing with the loading of plugins, not the plugins themselves.
More precisely, the latest version of PyGObject made the Python 3 loader of libpeas1 unusable (libpeas provides the plugin engine for gedit and other apps). libpeas1 and gedit depend on GIRepository-2.0 while the latest version of PyGObject has upgraded to GIRepository-3.0. It is not possible to use both GIRepository-2.0 and 3.0 at the same time in the same process. (Link to the issue).
It's like weeds growing. If you do nothing, weeds grow and regression bugs happen. Note that it doesn't mean that nothing is done in gedit, there is still development done. But the GTK and GNOME platform apparently moves faster.
gedit is no longer developed and maintained by a team of 5-6 dedicated hackers. So the project is no longer able to lead the peloton, but the application is still there and remains useful for many people! We (or - mainly - I) don't have the human resources to keep up with everything and be ahead of all the things to do. Hence ...
Reducing/changing the scope of gedit
gedit has for many years been between two things. (1) A great and easy-to-learn tool for beginners. And (2) some powerful plugins are or were available, so the text editor is also suitable for more advanced users, also in a professional context.
So the scope of gedit is a bit unclear. What is clear is that we want from gedit something more than just writing quick notes. So something more than a simple notepad. But not as powerful and complete as Visual Studio Code (for instance, but you can pick your favorite IDE here, or Vim, Emacs).
What is also clear for the path forward is a desire to well support markup languages like HTML, Markdown, etc. To support them even better than now, by adding some useful features for such languages.
So in the context of the plugins removal, it means that some of them will not be re-implemented in C (or Rust or whatever). The set of features available through plugins will thus change. At least for the official plugins that are shipped with the gedit and gedit-plugins packages.
Did I mention Rust?
Even though there is a desire to deal with less programming languages, ideally having a single-language project, there is Rust.
Rust might be the exception. Maybe (without doing any promises), third-party plugins can choose Rust instead of C. That would make for a better experience. Then, maybe, a Rust third-party plugin will eventually find its course into gedit proper.
The impact for users
This commit is the place to go to have the list of plugins that were implemented in Python and have been removed.
But for the moment the Flatpak of gedit is mostly unaffected, because it can use the previous version of PyGObject while using the latest GNOME runtime.
gedit on the Microsoft Store is also unaffected.
One day however, the updates of gedit and gedit-plugins will roll out. Versions >= 48.2 are already affected. The idea is to re-implement in C a few plugins so that the change is not too disruptive for Flatpak and Windows users.
As a conclusion, let's see what the future of gedit has in stock! Be it attracting Rust developers, or being a tool of choice for certain uses, remaining humble at its task of being an easy-to-learn and general-purpose text editor.
This article was written by Sébastien Wilmet, currently the main developer behind gedit.