Jonathan Sauer wrote:
And while we're at it: Should string.uppercase and string.lowercase use the \lccode/\uccode tables? [...] 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.
Then I think string.uppercase and string.lowercase should point to the corresponding function in the unicode library to prevent confusion and bugs. Or is there a reason to keep the old functions around?
Nothing other than that they come from the core lua distribution. We have been talking about implementing our own utf-8 aware string functions instead of the current mix of core lua 8bit and unicode extension library functions. But there has been no time to do anything about it yet.
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.
I do not quite understand which part of the above text you are adressing. Which one is a bug? The global assignments made from Lua, or the reassigning of [no_local_whatsits]? Inferring from Hans' mail, I would suspect the latter.
Sorry for the confusion. The [no_local_whatsits] is an Aleph artifact that could be removed from the output, but is totally harmless. The use of global versus local assignment is totally random right now, and that is the bug I was talking about. Best wishes, Taco