4 ms·

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 anyth

by jordigh 11y ago

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 11y ago
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 11y ago
  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.
  - ArneBab 11y ago
    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.
  - kazinator 11y ago
    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?
- ArneBab 11y ago
  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.
  - gaius 11y ago
    That's insane, frankly. Emacs is supposed to be its own OS with a text editor as an afterthought...
  - kazinator 11y ago
    > Emacs 24 required a new udev, which required a new kernel version By chance, might this actually be systemd-related screwup? Just checking!
    - watersb 11y ago
      Gentoo probably avoids systemd, uses OpenRC instead.
Scarblac 11y ago
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.
agumonkey 11y ago
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 ?
jandrese 11y ago
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.

by jordigh 11y ago

kazinator 11y ago

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 11y ago
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.
- ArneBab 11y ago
  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.
- kazinator 11y ago
  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?
ArneBab 11y ago
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.
- gaius 11y ago
  That's insane, frankly. Emacs is supposed to be its own OS with a text editor as an afterthought...
- kazinator 11y ago
  > Emacs 24 required a new udev, which required a new kernel version By chance, might this actually be systemd-related screwup? Just checking!
  - watersb 11y ago
    Gentoo probably avoids systemd, uses OpenRC instead.

Scarblac 11y ago

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.

agumonkey 11y ago

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 ?

jandrese 11y ago

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.