[2496] in testers
Re: Bug about emacs not finding discuss
daemon@ATHENA.MIT.EDU (Calvin Clark)
Sat Jun 25 15:38:56 1994
Date: Sat, 25 Jun 94 15:38:44 -0400
From: Calvin Clark <ckclark@MIT.EDU>
To: yandros@MIT.EDU
Cc: epeisach@MIT.EDU, vrt@MIT.EDU, rel-eng@MIT.EDU, testers@MIT.EDU,
epeisach@MIT.EDU
In-Reply-To: "[3260] in Release_Engineering"
> I'm interested in wether all those command-line options want to be
> added back in now. No other version of emacs that I know of has them
> or will have them; the FSF way to do what Jonathon wanted is `emacs
> -rn foo'. When I talked to Calvin about the integration he did
> (adding those options Way Back When) he said he'd regretted it, and
> when I was approached about building emacs for solaris, I was told
> that I could leave those out, at lesat for the first round.
>
> Is now the time to get rid of these options and educate the users? Or
> perhaps should we wait and take that change whenever we migrate to
> emacs19?
>
> This seems mostly like a user-education issue, so perhaps testers
> isn't the best place for it. I'm not going to forward it to
> release-77, but anyone who knows where it `should' go should feel free
> to forward it, please. :-)
My short answer is "keep those options in for Emacs 18, because it's
easy enough to do; forget about them for Emacs 19, because then
everything will be different anyway." The rest of this message is my
long answer, and has more to do with the future of Emacs 19 than with
Chad's question.
The "X toolkit"-style options date historically to an Athena GNU Emacs
18.54 release where Rob French used a Shell Widget to support
cut-and-paste, among other things. When I did 18.57 for Athena, I did X
selection code in Xlib and did not use the toolkit, but it was decided
that enough people had gotten addicted to the toolkit options that they
had to remain, so I wrote a number of them by hand.
In retrospect, I think it was a mistake for Athena to modify Emacs in
any but the most minimal respects, unless such modifications would also
be accepted by the FSF. The approach that I've taken with Emacs 19 in
the emacs19 locker is to leave it pretty much as the FSF ships it, with very
few exceptions. These exceptions are:
1. Kerberized movemail, modify rmail-primary-inbox-list
so that rmail works.
2. Path names to mh programs so that mh-rmail works.
3. Path name to inews and other things so that GNUS works.
(GNUS 4.1 is bundled with Emacs 19.)
4. Auto-save files in /usr/tmp, rather than in the current directory.
5. Old ispell.el/ispell until the FSF gets their butts in gear and decides
what to do with future versions of ispell. Some day ispell3 will
probably replace ispell, but its a lot tougher to build and install,
even though it's far more powerful.
6. site-lisp directory with Emacs Discuss code and clu-mode.el.
So far I have not gotten a single complaint about this level of
integration, but this is partially due to the fact that most users of
Emacs 19 on Athena are power-users who won't faint if behavior/features
change once in a while.
I don't think this should happen for another year or so, but at some
point Athena will have no choice but to move to Emacs 19 as the default,
for various reasons:
1. Bit rot. Emacs 18 won't keep up with new platforms
and upgrades in vendor operating systems.
2. Embarassment. People from other universities will
think that we're still in the Stone Age if Athena is
still using Emacs 18 in 1996.
3. Compatability with the rest of the known universe.
Eventually most freely available Emacs Lisp packages
will simply not work on Emacs 19. I can name some
important packages that already fall into this category.
This is another kind of "bit rot."
4. Demand from faculty. (This may not be obvious yet,
but I've gotten whiff of it. It'll happen.)
There is no question that that the 18->19 move will have at least as
much impact as the move from CCA Emacs to GNU Emacs had. Consultants
will have some extra work helping people port their .emacs and
.Xresources files to Emacs 19, but they love to do that any way; the
last time I checked, consultants were beating each other on the head
with blunt intruments for the privilege of grabbing an Emacs question.
An approach similar to that taken with the CCA -> GNU switch could be
used again for Emacs 18 to 19. I/S wouldn't collapse into chaos,
continents wouldn't fall into the ocean, galaxies wouldn't explode.
(Well, actually, all of these things may happen eventually, but it
won't have anything to do with Emacs. :-)
