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
