Babyl on OZ and XX are now synchronized

[Rob Austein <SRA@XX.LCS.MIT.EDU>]

    Date: Sunday, 27 September 1987  20:30-EDT
    From: "Leonard N. Foner" <FONER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>

    Hookay.  I've finished synching OZ's Babyl to XX's.  My wart on ECC's
    original kluge has been transformed into something more palatable.

    What isn't done:
    o  The EMACS 165/EMACS 169 issue.

I installed OZ:<EMACS>EMACS.INIT.50 on XX, seems to work.

    o  I haven't even looked at the ITSen to see what their state is.

Should be ok.  You probably want to be very paranoid about installing
new stuff there, but I believe that things are in something
aproximating a consistant state.

    o  JBA, I haven't acted on the hack you mentioned to me.  It won't
       happen today (I'm waiting to see if I blew it somehow), but
       probably later in the week.

    What happened:

    I have installed the most recent versions of BABYL and BABYLM from XX.
    There were some problems, but things appear to be working okay now.

    First, the stuff in XX:PS:<EMACS>BABYL.OZ-INIT-KLUDGE doesn't quite
    work.  I'm reasonably sure it's a quoting issue:  the ^]'s in the
    string cause ?QNS errors (evaluation of q7 is probably happening too
    early) if I try to set the variable that way, and using ^A in place
    doesn't cause errors, but the ^A'd items don't seem to match any
    strings.  I haven't taken the time to figure this out; since the whole
    thing is OZ-specific anyway, I've just substituted MIT-OZ (what would
    have been in q7, the idea of the ^]7's) in place.  That variable is
    now in OZ's SITE.INIT.

Obviously a brain bubble on my part, I just moved the kludge code into
a new file and forgot about it.  Using a literal MIT-OZ instead of ^]7
sounds ok.

    Second, it appears that the process of dumping a Babyl *never* reads
    SITE.INIT, nor does the dumped Babyl read SITE.INIT when it comes up.
    Hence, the variable setting in SITE.INIT will not take effect for
    dumped Babyl's.  (Use @SET TRAP FILE if you don't believe me...  I
    found it rather odd, too, since TECO.INIT *is* read, and it sets
    *Initializations* to have the right pathname for SITE.INIT.
    *Initializations* should get run on entry to ^R mode, and then
    EMACS.INIT reads SITE.INIT, but this isn't happening for the
    dumping-Babyl case because it never reads EMACS.INIT.  I haven't
    pursued this any further than that.)

    What I did to fix that was to embed the variable in the
    DUMP-BABYL.INIT file as well.  This doesn't seem to me to be a great
    idea, since I don't know if that file is sent in a distribution, and
    furthermore it means that both locations have to be updated (there are
    comments in each location that points at the other).  I'm not sure if
    instead maybe DUMP-BABYL.INIT should read the contents of SITE.INIT or
    EMACS.INIT.  That seems to be the best way to solve the problem, but
    there might be a screw that I don't know about.  If nobody can think
    of one, I'll try that solution instead in a week or so.

The comments in DUMP-BABYL.INIT are wrong, EMACS.INIT isn't run by
TECO.INIT, what happens is that *Initialization* is set up to run
EMACS.INIT the first time ^R is entered.  But standalone BABYL has its
own *Initialization* routine, which is set up in DUMP-BABYL.INIT and
overwrites the normal *Initialization*.  DUMP-BABYL.INIT never enters
^R.  Thus EMACS.INIT (and SITE.INIT) are never run.  This last is
probably a bug.

The easiest thing would be to run EMACS.INIT explicitly from
DUMP-BABYL.INIT.  If that causes problems, move the OZ specific stuff
to DUMP-BABYL.SITE-INIT and make everything else run that file.