[Dev-luatex] Assignments in TeX's mouth, or: "Dr. Zaius, it can talk!"

Taco Hoekwater taco at elvenkind.com
Tue Aug 14 12:57:16 CEST 2007

```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

```