[luatex] Negative value(s) of \endlinechar
David Carlisle
d.p.carlisle at gmail.com
Wed May 21 10:37:38 CEST 2014
Taco wrote
>>* * David Carlisle detects that \endlinechar has only one
*>>* negative value `-1’
*
> True, but that is just an implementation detail.
Well yes/no it's not _just_ an implementation detail: I was trying to fix a
bug in the current re-defintion of \typein in lualatex which had been
redefined to avoid the 127 restriction (the redefinition in current
lualatex makes it unsafe to use a # in the.value supplied on the terminal)
latex normally adds 1000 to \endlinechar to disable it temporarily and
subtracts it again to restore the old value.
as the restriction on being <127 was documented I thought I'd just switch
it to subtracting -1000 (which gave no error) and was surprised to get an
error when 1000 was added back. So documenting it at some point would be
nice but it's not a big deal especially as you say the restriction is
planned to go in the end.
(I posted a fix to \typein to the texlive list )
The reason the endlinechar was saved/restored this way in the original
rather than setting it in a local group was to save a few tokens so that
latex2e would load on emtex:-)
While testing typein I noticed another difference between pdftex and luatex
that I don't know is intended or not:
\read15 to \zzzz
\bye
in tex/pdftex/xetex produces
\zzzz=
but in luatex produces
\zzzz =
with a space after the command name.
This probably only makes a difference to people running diff over logs as
part of a regression test suite:-) But since it does make a difference
could you confirm whether it's intended to be like that (and we should
accommodate it while normalising any test logs) or if it is likely to
change.
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/luatex/attachments/20140521/85a87fe4/attachment-0001.html>
More information about the luatex
mailing list