Editing multiple package files

[Tim McNerney <TIM@MIT-MC>]

    Date: Thu, 18 Apr 85 13:10 EST
    From: Daniel L. Weinreb <DLW at TENEX.SCRC.Symbolics.COM>
    To:   TIM at MC.MIT
    cc:   common-lisp at SU-AI.ARPA
    Re:   Compilation and package system, an addendum

        Date: Thu,18 Apr 85 01:22:26 EST
        From: Tim McNerney <TIM@MIT-MC>

        Yes, there could be an arbitrary amount of hair, but there is a big
        difference between assuming that an entire file will be read in the
        package declared by the -*- line and supporting lusers who want to
        generate the screw cases you allude to above.  Once the package
        environment is established, simply having the ZMACS keep a package
        attribute for each section will support editing files like patch files
        which need to be read in a number of different packages.

    You seem to be saying that the high cost can be avoided by not
    supporting "lusers" who generate the "screw cases".  In other words, the
    editor should not actually parse the entire file, because that costs too
    much, and it's OK if it does the wrong thing for the screw cases.  I
    could be convinced of that principle.  So, what is your counterproposal?
    Exactly what will the editor do when a file is read in, such that it
    does all the right things except in "screw cases"?  How does it know
    where to stop parsing?

    And if you expect the editor to work correctly on files like patch
    files, with different package environments in each section, then you
    certainly do need to scan the entire file.  If you disagree, what's
    your countersuggestion?

No, not at all.  You seem to have misunderstood me completely (This
probably stems from your not having read the message that my message
(above) was an addendum to).  

The original message merely suggested that since the editor has to
scan the file at least once, namely when the file is first being read
into the buffer (during "sectionization" in Zmacs' case), that the
editor record the package for each definition at that time.  The
"screw cases" that I refer to are those where a NON-TRIVIAL package
environment is set up BY THE FILE BEING READ IN.  As I said, once the
package environment is stable, having the editor support multiple
package files is more tractable.