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.
yay!
Next wish: cc-mode drops support for XEmacs and ancient versions of GNU Emacs..
Less is more? Then more less is more more!
Thank you for caring for this much and thank you for the sanity you brings to gnus’s source! Not only contridutors, but also users will enjoy this while reading the source, an may be more likely to contribute.
How I imagine the the Tram Maintainer: https://commons.wikimedia.org/wiki/File:New_Zealand_-_Tram_driver_-_9596.jpg
You are being asked to login because oub@mat.ucm.es is used by an account you are not logged into now.
By logging in you’ll post the following comment to It’s About Ethics in Gnus Development:
Emacs installation.
When using the latest git version, in my experience it is better to do
cd emacs
./autogen.sh
./configure
make bootstrap
make
if you are on debian/ubuntu it is even better to do
cd emacs
./autogen.sh
auto-apt run ./configure –prefix=/opt/emacs25/
make bootstrap
make build
sudo checkinstall
this way you generate a deb pkg which can be de installed if needed
Uwe Brauer
I don’t really see why you’d want to do all that unnecessary typing, but you’re free to do so if you want, of course.
in order to generate a deb, it is recommended to run auto-apt before
checkinstall.
https://help.ubuntu.com/community/AutoApt
as for the unnecessary commands:
http://ergoemacs.org/emacs/building_emacs_from_git_repository.html
I think there is a “make uninstall” command as well.
But thi is still great to know how to package emacs, thank you.
Gnus Gnus Gnus
Thanks, Lars!!!
Hi Lars, I just built Emacs 29.0.50, when I M-x gnus I get 5.13, no Ma Gnus whatsoever. Was it dropped? I cannot find updated info by googlin’.
5.13 is Ma Gnus.
D’OH!
Thanks… I had to dig into versioning.