[Dev-luatex] Notes

[Jonathan Sauer]

Hello,

some miscellaneous notes while playing with LuaTeX 0.20.0:

-	Currently, the 'open_read_file' callback is only used if a
	'find_read_file' callback is registered as well. Since on Apr 24
2007,
	Taco wrote on the mailing list (subject '\input does not look at

	open_read_file callback?') that this would be fixed, I suspect
that 
	this is a bug.

-	I want to register an open_read_file callback that is called to
open 
	the job file. \everyjob is executed after the job file has been 
	opened, so I cannot use it to register the callback. Also,
callbacks 
	are not dumped into the format file, so I cannot register the
callback 
	while creating the format.

	What now?

	-	I could use the command line switch "--lua" to execute a
special
		script which registers the callbacks (and deal with the
fact that
		I cannot use kpathsea to locate this script)?

	-	I could call luatex not with the file name but like
this:

			luatex -jobname <filename> '\input <filename>'

	-	[insert simple and elegant solution]

	(On Apr 02 2007, Taco wrote on the mailing list (subject 'LaTeX
and 
	LuaTeX'), that dumping of callbacks could be added. If there was
a 
	vote on this, I would vote with 'yes' :-)

-	The following command line crashes LuaTeX with a bus error (yes,
yes
	the bus that people are riding on without a ticket):

		luatex '\directlua0{texio.write("term and
log","Hello")}'

	No destination or destination "term" works.

	The problem seems to be that LuaTeX wants to log to the log
file, but 
	the log file is not open yet.

	Stacktrace (not very useful, I'm afraid, since the symbols are
missing):

	0   libSystem.B.dylib 	0x9003fd9c putc + 60
	1   luatex            	0x0000d3e4 0x1000 + 50148
	2   luatex            	0x0000d9e8 0x1000 + 51688
	3   luatex            	0x000a74bc 0x1000 + 681148
	4   luatex            	0x0015c5d0 0x1000 + 1422800
	5   luatex            	0x00164310 0x1000 + 1454864
	6   luatex            	0x0015c6a4 0x1000 + 1423012
	7   luatex            	0x0015bab4 0x1000 + 1419956
	8   luatex            	0x0015ca6c 0x1000 + 1423980
	9   luatex            	0x0015ab10 0x1000 + 1415952
	10  luatex            	0x000a5878 0x1000 + 673912
	11  luatex            	0x0003c850 0x1000 + 243792
	12  luatex            	0x000238b4 0x1000 + 141492
	13  luatex            	0x00023de4 0x1000 + 142820
	14  luatex            	0x00068004 0x1000 + 421892
	15  luatex            	0x0000cf04 0x1000 + 48900
	16  luatex            	0x00070694 0x1000 + 456340
	17  luatex            	0x00001d54 0x1000 + 3412
	18  luatex            	0x00001bfc 0x1000 + 3068

-	Is it sensible to point the string functions, which are not
	Unicode-aware, to unicode.utf8, or are there situations (due to
	differences in functionality) that still require the original
string
	functions? (I would suspect that the original functions are a
bit
	faster)

-	lpeg does not seem to be UTF-8-aware. Is this impression
correct? If
	so, how should one proceed to use it safely? I would estimate
that this
	is mainly a problem when matching using a set ("lpeg.S")
containing
	characters outside the first 256 code points, since when
matching, a
	character is checked against each *byte* in the set string, not
each
	character.


Jonathan