The maximum length of scripts and listener fragments Decker can handle is based on how much bytecode the interpreter generates; there isn't a straightforward relationship between the length of the source code in characters/bytes and bytecode consumed, but suffice it to say the limit is "quite a lot".
Currently your block of code looks something like this, constructing a rich text table one character at a time by calling utility functions:
rtext.cat[ rtext.make["J" "bodyFrench"], rtext.make["'" "bodyFrench"], rtext.make["a" "bodyFrench"], rtext.make["i" "bodyFrench"], rtext.make[" " "bodyFrench"], rtext.make["v" "bodyFrench"], rtext.make["d" "bodyFrenchAccents"], rtext.make["c" "bodyFrench"], rtext.make["u" "bodyFrench"] ]
I'm hoping that the script you provided is itself generated by some other program. It would require vastly less source code and bytecode to instead directly generate a rich text table using contiguous character runs and Lil's "insert" form:
insert text font arg with "J'ai v" "bodyFrench" "" "d" "bodyFrenchAccents" "" "cu" "bodyFrench" "" end
The amount of bytecode with the above approach will still scale with the number of cells in the table. Yet another approach would be to pack your data into JSON (or similar) inside a string literal. The following script will generate a constant quantity of bytecode no matter how big that string literal is:
chars:"%j" parse "[{'t':\"J'ai v\"},{'t':'d','f':1},{'t':'cu'}]"
raze each v in chars rtext.make[v.t ("bodyFrench","bodyFrenchAccents")[v.f]] end
Make sense?
Irrespective of the benefits of taking a more data-driven approach, I would like to note that I am currently putting the finishing touches on some functionality that will make French text much easier to work with, so if you can be patient for about a week I think the issue will be moot.