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