[Aleph] Bug with \input

Giuseppe Bilotta gip.bilotta at iol.it
Wed Aug 25 20:02:02 CEST 2004


Wednesday, August 25, 2004 Javier Bezos wrote:

> Hello again,

> Sorry if I'm sending messages to make a nuisance of
> myself... ;-) but, here is another bug. An \input in a
> OCP reads only the first line of the file. For
> example:

[snip]

Thank you very much for the bug report.

I must say that I was fearing something like this; I even know
which part of the code is likely to cause this. I'm not 100%
sure on how to correct it, though.

Brief explanation: as you know, OTPs take the default input,
process it, and then feed their output back to into the input
stack, for processing either by the next OTP in the stack or by
the main parser, if we ran out of OTPs. In doing so, they
directly manipulate the input stack in a funky way.

In a *very* abstract way, this kind of behavior can be
assimilated to that of the \scantokens primitive in e-TeX: take
some input, reprocess it (\scantokens simply allows rescanning
of catcodes, OTPs allow much more messy stuff, and I'm still
fearing the moment when \scantokens/OTPs incompatibilities pop
up!), feed it back. \scantokens creates fakes input from a
pseudo file. OTPs manipulate the current input stack head
directly.

I'm afraid that the bug we're seeing depends on this. OTOH
tracing OTPs behavior is not exactly the easiest thing to do.
If this is indeed the problem, and it can't be fixed easily
with some pointer juggling, I'm having half an idea of
switching OTPs to the pseudo-file re-input strategy. It'll be
interesting to see what happens then (esp. when many OTPs are
involved ...)

-- 
Giuseppe "Oblomov" Bilotta



More information about the Aleph mailing list