[2662] in Release_Engineering
emacs
daemon@ATHENA.MIT.EDU (Calvin Clark)
Fri Jun 28 06:30:41 1991
Date: Fri, 28 Jun 91 06:30:34 -0400
From: Calvin Clark <ckclark@ATHENA.MIT.EDU>
To: eichin@ATHENA.MIT.EDU
Cc: rel-eng@ATHENA.MIT.EDU
In-Reply-To: "Mark W. Eichin"'s message of Fri, 28 Jun 91 05:36:25 -0400 <9106280936.AA26136@e40-008-6.MIT.EDU>
Reply-To: ckclark@mit.edu
>>>* RMAIL BABYL format has changed, so rmail will have problems with labels when
>>> reading RMAIL files generated by earlier versions of emacs.
> This sounds unacceptable to me; while the FSF may be sloppy
>about backwards compatibility, we've got enough users to consider this
>a problem.
Unfortunately, when I looked at it, I failed to see a simple way to
implement backwards compatibility for this purpose. If it's just a
matter of one search regexp which can be changed, then I'd fix it in a
second. But if it's going to be backwards compatible, it has to do it
the right way; i.e., if a user has an RMAIL file which was formatted in
the old style, then emacs must be able to read it in and manipulate the
labels properly, and if new messages are put there, the must be put in
the original style. On the other hand, if it's reading a BABYL version
5 RMAIL file, it should output the file in *that* format. Simply saying
we should use the old BABYL format because version 18.54 did it is not
good enough, because if people transfer their RMAIL files from other
systems running 18.57, and they can't read their mail here properly,
then it's admittedly not as bad since fewer people would then have
problems, but it's still bad. It would be the easiest thing to do, but
it's a political decision that I'm not going to make. Fortunately, a
backwards compatible version would only require elisp changes, not
source code changes, and hence no rebuild would be necessary. I'll look
at the problem some more. If you (or anyone else knowledgeable in
elisp) has time in the near future to talk about a good fix, then I'd
like to spend some time working it out. It would save a lot of
headaches for consultants and users if some solution is reached, so it
would be worth it.
>>>Known bugs:
> Another known bug (which I reported in testing and still
>hasn't been fixed *properly*): At least on the RT (I assume on the VAX
>too) loadst (and thus display-time) no longer displays the system
>load. This gratuitous removal of useful functionality had better at
>*least* be documented, but shouldn't have occurred in the first place.
>e40-008-6% /mit/emacs/rt/install/etc/loadst
>5:31am
>e40-008-6% /usr/athena/lib/gnuemacs/etc/loadst
>5:31am 0.56[0]
> _Mark_ <eichin@athena.mit.edu>
Mark, did you ever read the reply I sent to you about this? You're on a
*dialup* machine which does not allow setuid/gid mounts of NFS lockers.
emacsdev is an NFS locker. It will work when it gets put on the packs.
Try running the emacsdev loadst on a machine which allows setuid/gid
attaches, and you'll see that load average works. (It better...it's the
same loadst code that 18.54 uses.) It will *also* work on the dialup
machines when it gets on the packs, because the dialups trust their
system packs.
And if you're going to accuse me of gratuitously removing things from
emacs, I might as well confess that I gratuitously "removed" the X
toolkit from it, and about 200-300k of process size with it. :-)
-Calvin
