A proposal for removing obsolete Emacs packages | Hacker News Reader

A proposal for removing obsolete Emacs packages

comments.gmane.org

63 pointssohkamyung29 comments

I'm not opposed to removing stuff which is really, truly, obsolete, but I am concerned about removing useful functionality and never adding it back (c.f. gnome-screensaver, which destroyed the functionality xscreensaver offered and never restored it — it's been over a decade and gnome-screensaver is still not a replacement for xscreensaver!).

A good part of my concern hinges on the definition of 'obsolete.' Code for handling multi-byte characters on black-and-white Macintoshes? Probably obsolete. BBDB? Stagnant but not obsolete (it's sad, incidentally, that it is stagnant, but that's a post for another time).

The problem is such code can kill a long-running system. Bugs pile up in code no-one understands, or uses anymore. People are afraid to make large-scale refactorisations / modernisations to code bases as they will have to figure out how to upgrade/fix old stale code.

In the case of emacs I can imagine this situation is particularly bad -- lots of old code and limited developer time.

Anecdote is not data, but for Emacs has been pretty bug free. My impression is that things that get used tend to be robust and my belief is that bugs in code that isn't used isn't a problem. From the discussion on the proposal, my guess is that the people who tend to use obsolete packages are people who have been using Emacs for a really long time, and my feeling is that such people know what they are getting into.

That said, I guess my premise is that Emacs is a bit unlike a lot of software in that new users encounter problems with features and only very experienced users are likely to experience bugs. YMMV.

I never adopted gnome-screensaver (or any of the other parts of gnome that I could get away with; I tried using xsettings-daemon for a while but switched back to gnome-settings-daemon for some reason that I don't recall) for many reasons, but this was the nail in the coffin: https://wiki.gnome.org/Projects/GnomeScreensaver/FrequentlyA...

I like what Mercurial does: never remove anything, no matter how obsolete. In Mercurial, "obsolete" just means it won't show up in the docs or the wiki or anything. The code is still there, but nobody talks about it, and nobody has to use it. Also, nobody has to fix it. Sure, it's a bit annoying as an hg dev that we can't get rid of any public functionality, but hg users are much happier that the scripts they wrote ten years ago against hg still work today. It doesn't mean that progress can't happen; it just means that progress can't trample other people's habituation.

Emacs has been around for over 30 years or even 40 years, depending on how you count. People have come to rely on all sorts of behaviour since the dawn of time. Changing that behaviour just to make the developers a little less annoyed is completely at the expense of the users.

I reiterate some of Steve Losh's here,

     Allow me to illustrate this with a helpful Venn diagram:

                      -------
                     /3333333\
                    |333333333|
                     \3333333/
                      -------

    11 -> People who give a shit what a program's codebase
    11    looks like.

    22 -> The authors of said program.
    22

http://stevelosh.com/blog/2012/04/volatile-software/

This attitude leaves the project hamstrung with old misfeatures. Sometimes externally-visible functionality isn't outright broken, but badly designed in some way, like exhibiting a nonsensical corner case or whatever. People "out there" depend on that behavior, though. Their scripts might break if it is changed. You really want to fix it.

There are ways forward, like supporting a backwards compatibility mode which emulates the old behavior. For instance --emulate-version=6 could make version 7 behave like 6 with regard to changes like this. At some point, you cut off support for --emulate-version values of 6; the program then fails with a message saying "Version 17 can only emulate quirks from version 8 and newer." and bail.

If people want the old behavior, they can use an older version of the program.

I think the situation is different for Mercurial. Since every hg client has to be able to inter-operate with any hg client from any other machine, regardless of whether it's been updated or not, it makes sense to retain old functionality, so that newer clients can still talk to older ones. I believe rsync also does a similar thing, where it has some kind of system to figure out the highest version of the rsync protocol supported by both sides, and newer rsync versions support all the old versions of the protocol. Emacs is not in this position. Multiple versions of Emacs can always inter-operate as long as they can all read and write text files.

Two things: I suspect that not every feature of the client has to do with protocol or repo format interoperability. Secondly, things can change in that regard, too. Secondly, formats and protocols can be subject to versioning and obsolescence also. In short, the situation is not different.

> Multiple versions of Emacs can always inter-operate as long as they can all read and write text files.

What? No; Emacs is a language implementation, changes in which can easily break old code. Sure it can read some elisp file you wrote in 1991, but will it work?

You will have multiple Emacs versions on your devices — all using the same .emacs.d with only minor patches. And your friends will use your adaptions, too.

Emacs isn’t just a text editor. It is an environment for elisp programming.

Using an old version often isn’t feasible.

For example I lost sound support on my Gentoo OLPC because I had to update my Emacs to 24 to support my .emacs.d from my desktop without endless compatibility issues. Emacs 24 required a new udev, which required a new kernel version, which did not support the audiocard properly.

Result: No more hacking with music in the train for me.

@steve: Thank you for that article! I hadn’t seen it yet.

> Emacs 24 required a new udev, which required a new kernel version

By chance, might this actually be systemd-related screwup? Just checking!

Gentoo probably avoids systemd, uses OpenRC instead.

That's insane, frankly. Emacs is supposed to be its own OS with a text editor as an afterthought...

I kinda agree with all this. And at the same time I'd love an emacs sandbox with zero embedded features. Are there projects that maintained two parallel lines ? is it stupid ? too costly ?

This is also great news for attackers looking for old disused code with long neglected security vulnerabilities. It's also a potential nightmare for people trying to refactor the code. They never know when they might break one of these ancient and otherwise never-talked-about features that only a small handful of people even know about.

It's developed by volunteers though. If you want to keep people interested in helping with the project, it had better not be extremely frustrating to work on.

Would it be easy to include suggested replacement packages? This would help people bring forced to upgrade.

My .emacs is ancient, and I'm pretty sure there's tons of obsolete elisp packages.

Thx!

https://xkcd.com/1172/

We should also remove obsolete wiki.

cf http://batsov.com/articles/2012/03/20/die-emacswiki/

And try to make an awesome replacement, with an attractive website. Like http://spacemacs.org/ ;)

(I saw some initiatives such as http://nicolas-petton.fr/ressources/emacs-website/)

come on, we are in #b11111100000 !! =)

If you look at the edits in the past month for emacs wiki and wikemacs, emacswiki is still the place to go:

http://wikemacs.org/index.php?title=Special:RecentChanges&da...

http://www.emacswiki.org/emacs?action=rc;days=28;all=0;showe...

It sounds like a reasonable plan to me. I didn't even know longlines-mode was obsolete.

Would suggest that obseletion messages should also have optional space to include suggestions about what packages are not obsolete that may fill the same space. I had to google for "visual lines mode" being the successor.

Seems like a change that would break a lot of configurations for users.

Those users would be warned about the breakage well in advance under this proposal. They can choose not to upgrade Emacs, or choose to switch to a non-obsolete replacement package for their desired functionality, or choose to complain that the feature should not be removed because it has no replacement.

and when they complain, what would the answer be?

Would there be a complain-button next to the deprecation warning?

Fortunately, Emacs does not auto-update.

Thank ${DEITY} :D

(Thank 'DEITY)

They can't even remove obsolete code (c.f. http://emacshorrors.com/posts/forget-me-not.html) why do we think they'll be able to remove obsolete packages.

That obsolete code has been removed for decades. It's only left in the file in a commented-out form because it is the only documentation of the behavior of the original function. Are you complaining about the poor documentation practices of an open source project in the early 1980s?

Reply on news.ycombinator.com