[tex-k] [comp.text.tex] web2c wish...

[David Kastrup]

Michael John Downes <mjd@ams.org> writes:

> David.Kastrup@t-online.de (David Kastrup) writes:
> 
> > What global state?  My proposal was to use the fork system call in a
> > more or less pristine state of LaTeX (either after reading in the
> > format, or even after reading the preamble): the forked process
> > modifies its own copies of the variables.  When it finishes, the
> > parent from which the forks are generated is still in pristine state.
> 
> OK. Blame it on my ignorance that I did not understand the implications
> of your proposal.
> 
> But then I have another question: If the parent remains in a pristine
> state, what do you plan to do---if anything---for typesetting something
> less than the full document? If you typeset only the third section out
> of four, then the section/subsection numbers will show up as 1, 1.1, 1.2
> instead of 3, 3.1, 3.2, I suppose?

Depends on what mechanism one employs.  If your parent has been put
in lurker mode just after having finished the previous section, no
problem.

My approach was more or less the simple-minded one.  A more elaborate
mechanism (where effectively repeat \dump s are generated) is
presented in

<URL:http://www.ntg.nl/eurotex/strokov.pdf>

If one wanted to make use of more than one "checkpoint", keeping
in-memory forks around will obviously not be the best choice.

In this case, an IPC approach where one could feed TeX code (such as
\input{...}), request a \dump (including flushed file pointers!), feed
it back a dump, perhaps even receive dvi, would be best.  The
management of dumps and the like would then be delegated to a
different executable, putting into the web2c TeX only the necessary
hooks.  One TeX channel might be reserved for IPC communication: if
TeX does a \write into that channel, the socket would receive a
message to that effect, if TeX does a \read there, the socket would be
notified and then TeX would block until something appropriate got sent
to the socket.  That way, quite a few different applications could be
designed, and tested independently of the release cycle of the web2c
stuff.  Of course, such a thing would need more working out than my
previous request, but would be wagonloads more flexible.  And the
lack of "fork" would be a boon for operating systems where this could
turn out problematic.  Of course, on those systems one would probably
have to take a look at the offered IPC mechanisms, too.

> Or how about an equation containing a \ref or other pointer to
> information outside the fragment being processed?
> 
>   \begin{equation}
>   a=b+c\quad\text{by applying (\ref{xyz})}
>   \end{equation}
> 
> Offhand it would appear that if the referenced label was in a
> pre-existing .aux file, no problem, but if it was a \label added during
> the current writing session, the ref would presumably show up as
> undefined.

Yes.  I don't care about the intricacies: the things needing more
than one run.

> I expect that the practical answer would be: just let LaTeX print
> question marks as usual, in the case of a document fragment, and let the
> users understand that if they want absolutely everything resolved they
> have to do a full document run to ensure that the aux file is updated.
> 
> But if you're talking about a programmable editor (and I think you are
> :-) the ideal thing to do would probably be to catch the addition of new
> labels and do something to ensure that an appropriate call of \newlabel
> gets done in some kind of mini-preamble when processing document
> fragments.
> 

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de