Misc news about the gedit text editor, mid-July edition! (Some sections are a bit technical).
gedit 49 in preparation
About version numbers: if all goes well, gedit 49 will match GNOME 49 and are expected for September! So gedit will be back on track to follow the GNOME version numbers. This is after some trials to not follow them, to release gedit versions when ready and more often, but at the end of the day this doesn't change much.
Gedit Development Guidelines
I've written the Gedit Development Guidelines, a series of small Markdown documents. It regroups the information in one place. It also documents stuff that needed to be written in commit messages, so to avoid repetition and to have more complete explanations, commit messages can now refer to the guideline documents.
Be warned that some of the gedit guidelines don't follow the more modern GNOME development practices. The rationales are clearly explained. In my humble opinion, what is deemed "modern" doesn't automatically make something better. (If you read this and are a developer of one of the modern things not used by gedit, take it as a user feedback, and remember that what truly matters is that the GTK development platform is still appreciated!).
Improved preferences
There is now a "Reset All..." button in the Preferences dialog. And it is now possible to configure the default language used by the spell-checker.
Python plugins
Most Linux distributions ship some older versions of some GNOME modules to make Python plugins in gedit (and other apps) still work. There has been some disturbances in the air, but my hope is that everything will be back to normal for GNOME 49.
File loading and saving
There are some known issues with the file loading implementation, and I'm working on it.
About the old iconv() function, I've created a utility class called
GtkSourceIconv
to (try to) tame the beast, except that the beast cannot be fully
tamed, by design! Some aspects of its API are broken, and what I
recommend for new code is to look at the libICU to see if it's better.
But instead of doing ground-breaking changes in the file loading and saving
code (to switch to the libICU), I prefer a more incremental approach, and this
means to still use iconv() (for the time being at least). The
advantage is that incremental changes are directly useful and used; progress
is made on gedit!
I attempted a while back a new implementation in libgedit-tepl (TeplEncoding, TeplFile, etc). The problem is that I created a different API, so switching the whole of gedit to it was more difficult. And the new implementation lacked several important features used by gedit.
Now I'm moving some of my experiments done in libgedit-tepl back to libgedit-gtksourceview, because it's the latter (GtkSourceEncoding, GtkSourceFile, etc) that is used by gedit's file loading and saving machinery. libgedit-gtksourceview doesn't guarantee a stable API, and I consider it part of gedit, so it's more malleable code :-)