Hello, a few modifications to the manual (additions, mostly) as well as a small sample file illustrating the point made below: %&luatex \endlinechar=10 \directlua name{@test} 0 { -- Fail right away print('foo') assert(false) } \end While the stack backtrace for code created using \directlua is now very readable, IMO the same cannot be said for code loaded via loadfile, at least when kpathsearch is involved. Then the stack backtrace contains the absolute path of each Lua file, making it quite a mouthfull. I have created a patch for lobject.c that modifies the file name(s) contained in a stack backtrace by removing everything but the last path component, i.e. instead of "/absolute/path/to/the/lua/file/somewhere/in/texmf/file.lua", only "file.lua" is shown. What do you think? 190a191,202
/* get the last path component of the source */ for (;;) { const char* fn = strstr(source, LUA_DIRSEP); if (fn) { /* move past the directory separator and try again */ source = fn + strlen(LUA_DIRSEP); } else { /* no further directory separator: Done */ break; } }
Incidentally, I noticed that the code lua.bytecode[n] = loadfile(kpse.find_file(filename)) when used in IniTeX (to preload a complete Lua file) stores the file's complete path in the compiled Lua code (for the stack backtrace) which is then dumped into the format file. Since it is possible that the path contains private information, i.e. the user name, this private information would then be stored in the format file. OTOH, I do not think that this is a problem, since the format file will either be generated on the computer LuaTeX is installed on, and/or the preloaded Lua files will reside in the texmf tree which does not contain a user name et.al. Maybe a note in the manual (contained in the attached .diff) Jonathan