
A proposal for removing obsolete Emacs packages - sohkamyung
http://comments.gmane.org/gmane.emacs.devel/198007
======
wtbob
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).

~~~
CJefferson
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.

~~~
brudgers
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.

------
jordigh
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/](http://stevelosh.com/blog/2012/04/volatile-software/)

~~~
kazinator
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.

~~~
rcthompson
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.

~~~
kazinator
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?

------
asah
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!

------
golergka
[https://xkcd.com/1172/](https://xkcd.com/1172/)

------
AdrieanKhisbe
We should also remove obsolete wiki.

cf [http://batsov.com/articles/2012/03/20/die-
emacswiki/](http://batsov.com/articles/2012/03/20/die-emacswiki/)

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

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

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

~~~
ArneBab
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://wikemacs.org/index.php?title=Special:RecentChanges&days=30&from=&limit=500)

[http://www.emacswiki.org/emacs?action=rc;days=28;all=0;showe...](http://www.emacswiki.org/emacs?action=rc;days=28;all=0;showedit=0)

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

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

~~~
rcthompson
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.

~~~
ArneBab
and when they complain, what would the answer be?

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

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

~~~
rcthompson
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?

