I mean maintainability. Yeah.
This is long and meandering, so here’s the summary: Gnus (and a couple of other Emacs packages) are dropping XEmacs support. Meanwhile, here’s a GIF of a cat:
When I took over Gnus, the Emacs newsreader, in the mid-90s, it seemed natural to do the development outside of Emacs. Emacs was on a very slow and stately release schedule. In addition, it seemed vital to support many different versions of Emacs, since people were slow to upgrade Emacs, and there was the XEmacs fork which was superior in some ways. (Images! Fonts! Multi-lingualism! Yay!)
So Gnus developed its own ecosystem of compatibility functions to support everything from Emacs 18 to all the XEmacs version to the latest Mule-breaking Emacs releases.
Instead of assq-delete-all , there’sgnus-delete-alist. Instead of union, there’s gnus-union. And on and on. When reading the code, that’s not a good thing. Instead of having lots of familiar functions that you know what they do, you’re instead confronted by a barrage of functions that are unfamiliar. You have to look them all up to understand the code. Which means that only Gnus experts can understand the code.
Now, the last decade (or so) Emacs development has proceeded very swiftly. Emacs has gotten built-in support for HTML, lots of new Emacs Lisp constructs like when-let, pcase, new more functional libraries like seq, and support for lexical binding.
This hasn’t happened on the XEmacs side. XEmacs development has slowed way down.
In the last few years, whenever somebody has made even the most trivial change, the Gnus build bot would signal some breakage, which would then have to be fixed. Katsumi Yamaoka is really good at fixing these sort of things, but it leads to feeling of stepping on egg shells. You make a trivial change that takes 30 seconds, and then you either have to spend half an hour tweaking it to get it to build on Emacs 23 or XEmacs, or you dump all that work on Katsumi.
It’s not the most efficient way to develop stuff, and it feels discouraging. So for a couple of years I’ve been thinking of dropping support for anything but the Emacs mainline.
Installing and building the development version of Emacs on a modern GNU/Linux system is preposterously easy:
sudo apt-get build-dep emacs24 git clone git://git.savannah.gnu.org/emacs.git cd emacs make
And you’re done. You now have a fully-featured Emacs, built with all bells and whistles.
But I didn’t do anything about the situation, because dropping XEmacs support would be kinda dickish. It would make things easier for me, but I didn’t want to be a dick.
Then, the last few weeks, these things happened:
- Stephen J. Turnbull, the XEmacs maintainer, started discussing the possibility of ending XEmacs development.
- Michael Albinus, the Tram maintainer, dropped XEmacs support.
- Steve Youngs, the SXEmacs maintainer, set up a Gnus repo. SXEmacs approach to Emacs.
People say that Emacs is a “everything but the kitchen sink, and then the kitchen sink” kind of editor, but SXEmacs is all that, and a lathing workbench, a jetpack and a hydroponics plant.So I thought: Hey! Now I can do this! I can just let the eminently capable SXEmacs people worry about Gnus for XEmacs in the future, and I can bring Gnus “home” to Emacs.
I posted an outline and awaited reactions. And most people seem positive. David Engster, the CEDET developer, says that he’s pretty much doing the same thing. Org mode almost dropped XEmacs support earlier, but then changed their minds.
It’s not unanimous, understandably enough.
Dropping XEmacs support (and support for older Emacsen) is uncomfortable, and doesn’t make me happy. But I think it’s the way to proceed at this point.
The thought of making the Gnus code base less obfuscated does make me happy, though.
