[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