Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.86 "Naka-Tsurugi")
Content-Type: text/plain; charset=US-ASCII
Message-ID:  <199710071818.OAA17732@aleph.swift.xxx>
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
In-Reply-To:  Your message of "Tue, 07 Oct 1997 00:49:25 BST." 
              <m0xIMtx-000OWGC@dcarlisle.demon.co.uk>
Date:         Tue, 7 Oct 1997 14:18:49 -0400
From: Matthew Swift <swift@ALUM.MIT.EDU>
Sender: Mailing list for the LaTeX3 project
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
To: Multiple recipients of list LATEX-L
              <LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Extended include
Status: R

>>>>> "D" == David Carlisle <david@DCARLISLE.DEMON.CO.UK> writes:

    D> 2) To speed up
    D> processing of drafts as only the `current chapter' need be
    D> processed.

    D> (2) is not relevant if you are using a class where the
    D> individual sections are self contained documents. To just work
    D> on section1 you don't need to go \includeonly{section1} you can
    D> just go latex section1.tex

Hunh?  Like what kind of class is that?  Do I misunderstand what you
mean?  You can't just go latex section1.tex if it doesn't have a
\documentclass in it.  If it does, either you weren't using \input or
\include to include it in the first place, you were using something
like \includex; or you are using a sophisticated LaTeX front-end like
AUCTeX which supplies a header and footer for section1.tex from
somewhere else.

    D> processed.  3) To cope with big jobs where running the whole
    D> document in one go runs out of memory.

    D> So that leaves (3). But (3) is usually a forlorn hope. Often

I agree.  The only time I have ever had TeX memory size problems is
doing intensive fiddling with pstricks to cross-shade a large table.

A typical 300+-page document (source2e for example) doesn't tax TeX at
all, and we are about to enter the era of web2c-7 with dynamic memory
allocation.

When I tried the solution of one aux file and saving all the parts'
auxinfo in memory with macros (tag.sto, group.sto). I did some
experimentation and concluded that the extra memory usage was
irrelevant.  I don't say this would be so in all applications, of
course, but the result was encouraging.