Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f1DIiXH27855 for ; Tue, 13 Feb 2001 19:44:33 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1DIiWd02467 . for ; Tue, 13 Feb 2001 19:44:32 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DIiW728967 for ; Tue, 13 Feb 2001 19:44:32 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095ED.016BBE80" Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id TAA21529 for ; Tue, 13 Feb 2001 19:44:31 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1DIiV728959 for ; Tue, 13 Feb 2001 19:44:31 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <12.CA0923ED@mail.listserv.gmd.de>; Tue, 13 Feb 2001 19:44:06 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 488845 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 13 Feb 2001 19:44:09 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id TAA08177 for ; Tue, 13 Feb 2001 19:44:08 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id TAA27500 for ; Tue, 13 Feb 2001 19:44:08 +0100 Received: from server-13.tower-4.starlabs.net (mail.london-1.starlabs.net [212.125.75.12]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with SMTP id f1DIi6g14580 for ; Tue, 13 Feb 2001 19:44:06 +0100 (MET) Received: (qmail 18492 invoked from network); 13 Feb 2001 18:40:53 -0000 Received: from nagmx1e.nag.co.uk (HELO nag.co.uk) (62.232.54.130) by server-13.tower-4.starlabs.net with SMTP; 13 Feb 2001 18:40:53 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id SAA21166 for ; Tue, 13 Feb 2001 18:43:55 GMT Received: by penguin.nag.co.uk (8.9.3) id SAA06366; Tue, 13 Feb 2001 18:43:53 GMT In-Reply-To: (message from Hans Aberg on Tue, 13 Feb 2001 18:55:22 +0100) References: Hans Aberg's message of "Tue, 13 Feb 2001 15:10:54 +0100" Return-Path: X-VirusChecked: Checked Content-class: urn:content-classes:message Subject: Re: Side remarks about TeX input sequence Date: Tue, 13 Feb 2001 19:43:53 +0100 Message-ID: <200102131843.SAA06366@penguin.nag.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "David Carlisle" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3891 This is a multi-part message in MIME format. ------_=_NextPart_001_01C095ED.016BBE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > How can this be true? By magic, or the will of Knuth, or something. > What happens if a command in the middle of a line changes the catcodes makes no difference: the notion of line for the input buffer is = hardwired into the implementation it is not changable via TeX commands and does not depend on catcodes or the value of \endlinechar. > or contains a macro that expands to a \input ? The rest of the line of the original file sits buffered in one of those input streams until the input file finishes. Incidentally one reason why xmltex can not support utf16 is that TeX buffers to ^J (or ^M) and throws away any bytes with value 32 that occur at the end of this buffer, which might just be half of a 16bit quantity that you'd rather keep. there's no way to control this behaviour from within TeX. David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet = delivered through the MessageLabs Virus Control Centre. For further information = visit http://www.star.net.uk/stats.asp ------_=_NextPart_001_01C095ED.016BBE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Side remarks about TeX input sequence

> How can this be true?
By magic, or the will of Knuth, or something.

> What happens if a command in the middle of a line = changes the catcodes
makes no difference: the notion of line for the input = buffer is hardwired
into the implementation it is not changable via TeX = commands and does
not depend on catcodes or the value of = \endlinechar.

>  or contains a macro that expands to a = \input <filename>?
The rest of the line of the original file sits = buffered in one of those
input streams until the input file finishes.


Incidentally one reason why xmltex can not support = utf16 is that
TeX buffers to ^J (or ^M) and throws away any bytes = with value 32 that
occur at the end of this buffer, which might just be = half of a 16bit
quantity that you'd rather keep. there's no way to = control this
behaviour from within TeX.

David

________________________________________________________________= _____
This message has been checked for all known viruses = by Star Internet delivered
through the MessageLabs Virus Control Centre. For = further information visit
http://www.star.net.uk/stats.as= p

------_=_NextPart_001_01C095ED.016BBE80--