On 21 May 2014, at 10:37, David Carlisle <[email protected]> wrote:
> > 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) One depressing problem with TeX is that every weird bit of tex.web gets documented and used and counted on :( Ok, so I’ll have to change luatex’s \endlinechar to accept invalid negative values just to be compatible with the other engines. Not a big deal, really. > 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. That change will stay. The general ‘tex’ rule is that multi-letter csnames are followed by a space when printed. The fact that \read is actually an exception to that rule is just a bit too bizarre to allow for. Best wishes, Taco
