LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: David Kastrup <[log in to unmask]>
Date: Mon, 13 Jan 2003 23:48:46 +0100
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (49 lines)
The following message is a courtesy copy of an article
that has been posted to comp.text.tex as well.


Well, Christmas is over, and is the time to think about what would
have been nice to have in one's stocking.  Here is one thing I came
up with:

\begininput is just like \input, except for one thing: it gets no file
name argument.  Instead it uses the current input file without
changing the current input position.  When \endinput gets encountered,
it returns to the location where the current input file was when
\begininput occured.  Its manner of operation will be an immediate
switch of input context.  When \endinput is then encountered,
processing returns to the tokens from the macro and other input
context after \begininput until that gets exhausted back to the
original file, which then presumes processing at the position it was
when \begininput was executed.

What does this buy us?  It buys us a tabularx which can deal with
verbatim in its intestines and does not need to store its contents in
a macro.  It buys us an ltxtable that does not need to revert to a
separate file, yet will not overflow the memory in between.  It buys
us possibilities of looking over the same contents several times, yet
get error messages that point to the actual point where the error
originated (actually, this is the real reason I want it: it makes
sense in connection with preview-latex.  It would enable me to handle
tables and stuff in a more perfidious manner, first letting the whole
table be typeset, then generating  every cell on its own with the
proper width and shipping it out separately).

If we want to typeset example code including comments and newlines
and other stuff, say, using a verbatim-like environment or
listings.sty or whatever, it makes it easy to process this twice, get
error messages correctly if they occur, get catcodes naturally right
without having to do special tricks beyond what listings.sty already
offers and so on.

Disadvantage: won't work on a pipe unless one actually diverts the
read data somewhere.

But one might be able to live with that restriction.

What do the experts think: the functionality looks near to trivial to
implement.  Do you think it might be worth the trouble?

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

ATOM RSS1 RSS2