It’s About Ethics in Gnus Development

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:

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.

9 thoughts on “It’s About Ethics in Gnus Development”

  1. 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.

  2. 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

    1. I think there is a “make uninstall” command as well.

      But thi is still great to know how to package emacs, thank you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s