Jonathan Sauer wrote:
Note: According to the Lua reference manual, section 2.1, the definition of `letter' depends on the current locale. Would it be
Quite right. For that reason, luatex forces LC_CTYPE=C LC_COLLATE=C LC_NUMERIC=C while it is executing, I just never documented that. I will add a paragraph to the manual.
possible/sensible to define the current locale not according to the system TeX is run on (which would actually make LuaTeX code locale-dependent, since some identifiers might not work on another computer with a different locale) according to TeX's current catcode table?
Category codes are quite often changed dynamically, so that could become a problem in real life documents rather quickly, I'm afraid. But I have not given this subject much thought so far, perhaps there is a way to do it.
And while we're at it: Should string.uppercase and string.lowercase use the \lccode/\uccode tables?
Most probably not, for a few reasons. One: in the traditional TeX, \lccode/\uccode is related to font encodings as well as input parsing. I am not quite ready yet to drop those side-effects, but writing more code on top of the existing stuff is not a smart idea right now. Two: those tables are dynamic just like \catcode, and that would mean adding context-sensitivity to a quite low-level routine. Three: (and this is by far the most important one) using string.uppercase and string.lowercase is not a good idea. It is much better to use the unicode-aware functions in the unicode library.
When tracing assignments, the ones made from Lua are flagged as being \global (BTW: What are these messages about `reassigning [no_local_whatsits]'?):
That is a bug, actually. It is currently using a non-initialized stack variable for the global/local decision, and I could make it do either. Best wishes, Taco